* [PATCH 0/4] Series short description
@ 2010-11-22 0:31 Alexey Zaytsev
2010-11-22 0:33 ` [PATCH 1/4] fanotify: Shrink struct fanotify_event_metadata by 32 bits Alexey Zaytsev
` (3 more replies)
0 siblings, 4 replies; 32+ messages in thread
From: Alexey Zaytsev @ 2010-11-22 0:31 UTC (permalink / raw)
To: Eric Paris
Cc: Scott Hassan, Jan Kara, agruen, linux-kernel, stefan, Al Viro,
linux-fsdevel, Tvrtko Ursulin
Hi.
So, it's time for the second version of the the fanotify
range patches.
The patch adds modification ranges to fsnotify events. Fanotify
is made to pass the range to the users.
This is useful for backup programs that work on huge files,
so that only a part of a modified file needs to be scanned
for changes.
changed. This is particularly useful for backup utilities that
work on huge files, so that only a part of the modified file
needs to be scanned for changes.
The series is split into 4 patches. The first one breaks the
ABI (but not API), and should get in before the .37 release,
or not at all. The last patch extends the ABI to handle event-
specific data ('options') in a backwards-compatible way.
You can also get the patchies from
git://git.zaytsev.su/git/linux-2.6.git branch fsnotify
A modified fanotify-example is available from
git://git.zaytsev.su/git/fanotify-example.git branch range
Changes since the first RFC:
1) Reworked the user interface, see the last patch.
2) Handle event merges properly.
3) Pass the range to fsnotify_parent().
3) Various small cleanups and fixes.
---
Alexey Zaytsev (4):
fanotify: Shrink struct fanotify_event_metadata by 32 bits
VFS: Tell fsnotify what part of the file might have changed
fsnotify: Handle the file change ranges
fanotify: Expose the file changes to the user
fs/compat.c | 2 -
fs/nfsd/vfs.c | 2 -
fs/notify/fanotify/fanotify.c | 19 +++++
fs/notify/fanotify/fanotify_user.c | 132 +++++++++++++++++++++++++++++++-----
fs/notify/fsnotify.c | 24 ++++---
fs/notify/inode_mark.c | 2 -
fs/notify/inotify/inotify_user.c | 2 -
fs/notify/notification.c | 18 ++++-
fs/open.c | 4 +
fs/read_write.c | 4 +
include/linux/fanotify.h | 88 +++++++++++++++++++++---
include/linux/fs.h | 14 ++++
include/linux/fsnotify.h | 68 +++++++++++--------
include/linux/fsnotify_backend.h | 31 +++++++-
14 files changed, 330 insertions(+), 80 deletions(-)
--
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 1/4] fanotify: Shrink struct fanotify_event_metadata by 32 bits
2010-11-22 0:31 [PATCH 0/4] Series short description Alexey Zaytsev
@ 2010-11-22 0:33 ` Alexey Zaytsev
2010-11-26 7:01 ` Alexey Zaytsev
2010-11-22 0:33 ` [PATCH 2/4] VFS: Tell fsnotify what part of the file might have changed Alexey Zaytsev
` (2 subsequent siblings)
3 siblings, 1 reply; 32+ messages in thread
From: Alexey Zaytsev @ 2010-11-22 0:33 UTC (permalink / raw)
To: Eric Paris
Cc: Scott Hassan, Jan Kara, agruen, linux-kernel, stefan, Al Viro,
linux-fsdevel, Tvrtko Ursulin
And this saves additional 32 bits in the future
Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>
---
include/linux/fanotify.h | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/linux/fanotify.h b/include/linux/fanotify.h
index 0f01214..9a7986f 100644
--- a/include/linux/fanotify.h
+++ b/include/linux/fanotify.h
@@ -86,10 +86,11 @@
#define FANOTIFY_METADATA_VERSION 2
struct fanotify_event_metadata {
- __u32 event_len;
- __u32 vers;
- __aligned_u64 mask;
+ __u16 event_len;
+ __u8 vers;
+ __u8 reserved;
__s32 fd;
+ __aligned_u64 mask;
__s32 pid;
};
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH 2/4] VFS: Tell fsnotify what part of the file might have changed
2010-11-22 0:31 [PATCH 0/4] Series short description Alexey Zaytsev
2010-11-22 0:33 ` [PATCH 1/4] fanotify: Shrink struct fanotify_event_metadata by 32 bits Alexey Zaytsev
@ 2010-11-22 0:33 ` Alexey Zaytsev
2010-11-22 0:33 ` [PATCH 3/4] fsnotify: Handle the file change ranges Alexey Zaytsev
2010-11-22 0:37 ` [PATCH 4/4] fanotify: Expose the file changes to the user Alexey Zaytsev
3 siblings, 0 replies; 32+ messages in thread
From: Alexey Zaytsev @ 2010-11-22 0:33 UTC (permalink / raw)
To: Eric Paris
Cc: Scott Hassan, Jan Kara, agruen, linux-kernel, stefan, Al Viro,
linux-fsdevel, Tvrtko Ursulin
Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>
---
fs/compat.c | 2 +
fs/nfsd/vfs.c | 2 +
fs/open.c | 4 +++
fs/read_write.c | 4 +--
include/linux/fs.h | 14 +++++++++
include/linux/fsnotify.h | 68 ++++++++++++++++++++++++++++------------------
6 files changed, 64 insertions(+), 30 deletions(-)
diff --git a/fs/compat.c b/fs/compat.c
index c580c32..66eb689 100644
--- a/fs/compat.c
+++ b/fs/compat.c
@@ -1171,7 +1171,7 @@ out:
if (type == READ)
fsnotify_access(file);
else
- fsnotify_modify(file);
+ fsnotify_modify(file, pos - ret, ret);
}
return ret;
}
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 184938f..d781014 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -1035,7 +1035,7 @@ nfsd_vfs_write(struct svc_rqst *rqstp, struct svc_fh *fhp, struct file *file,
goto out_nfserr;
*cnt = host_err;
nfsdstats.io_write += host_err;
- fsnotify_modify(file);
+ fsnotify_modify(file, offset - host_err, host_err);
/* clear setuid/setgid flag after write */
if (inode->i_mode & (S_ISUID | S_ISGID))
diff --git a/fs/open.c b/fs/open.c
index 4197b9e..17b0d79 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -675,6 +675,10 @@ static struct file *__dentry_open(struct dentry *dentry, struct vfsmount *mnt,
f->f_path.mnt = mnt;
f->f_pos = 0;
f->f_op = fops_get(inode->i_fop);
+#ifdef CONFIG_FSNOTIFY
+ f->f_whatchanged.start = -1;
+ f->f_whatchanged.end = 0;
+#endif
file_sb_list_add(f, inode->i_sb);
error = security_dentry_open(f, cred);
diff --git a/fs/read_write.c b/fs/read_write.c
index 5d431ba..86c60c2 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -383,7 +383,7 @@ ssize_t vfs_write(struct file *file, const char __user *buf, size_t count, loff_
else
ret = do_sync_write(file, buf, count, pos);
if (ret > 0) {
- fsnotify_modify(file);
+ fsnotify_modify(file, (*pos) - ret, ret);
add_wchar(current, ret);
}
inc_syscw(current);
@@ -699,7 +699,7 @@ out:
if (type == READ)
fsnotify_access(file);
else
- fsnotify_modify(file);
+ fsnotify_modify(file, (*pos) - ret, ret);
}
return ret;
}
diff --git a/include/linux/fs.h b/include/linux/fs.h
index eedc00b..3337975 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -922,6 +922,16 @@ static inline int ra_has_index(struct file_ra_state *ra, pgoff_t index)
index < ra->start + ra->size);
}
+/*
+ * fsnotify wants to know, what might have changed during the file's lifetime.
+ * We maintain a single range, so it might include non-modified gaps, but this
+ * should work good enough for the majoroty of use cases, and the rest
+ * shold listen to individual 'modify' events. */
+struct fsnotify_range {
+ loff_t start; /* The beginning of the possibly modified area.*/
+ loff_t end; /* The first byte after the area. */
+};
+
#define FILE_MNT_WRITE_TAKEN 1
#define FILE_MNT_WRITE_RELEASED 2
@@ -965,6 +975,10 @@ struct file {
#ifdef CONFIG_DEBUG_WRITECOUNT
unsigned long f_mnt_write_state;
#endif
+
+#ifdef CONFIG_FSNOTIFY
+ struct fsnotify_range f_whatchanged;
+#endif
};
#define get_file(x) atomic_long_inc(&(x)->f_count)
diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
index 5c185fa..49e7788 100644
--- a/include/linux/fsnotify.h
+++ b/include/linux/fsnotify.h
@@ -26,12 +26,13 @@ static inline void fsnotify_d_instantiate(struct dentry *dentry,
}
/* Notify this dentry's parent about a child's events. */
-static inline int fsnotify_parent(struct path *path, struct dentry *dentry, __u32 mask)
+static inline int fsnotify_parent(struct path *path, struct dentry *dentry,
+ __u32 mask, struct fsnotify_range *range)
{
if (!dentry)
dentry = path->dentry;
- return __fsnotify_parent(path, dentry, mask);
+ return __fsnotify_parent(path, dentry, mask, range);
}
/* simple call site for access decisions */
@@ -53,11 +54,12 @@ static inline int fsnotify_perm(struct file *file, int mask)
else
BUG();
- ret = fsnotify_parent(path, NULL, fsnotify_mask);
+ ret = fsnotify_parent(path, NULL, fsnotify_mask, NULL);
if (ret)
return ret;
- return fsnotify(inode, fsnotify_mask, path, FSNOTIFY_EVENT_PATH, NULL, 0);
+ return fsnotify(inode, fsnotify_mask, path, FSNOTIFY_EVENT_PATH,
+ NULL, 0, NULL);
}
/*
@@ -78,7 +80,7 @@ static inline void fsnotify_d_move(struct dentry *dentry)
*/
static inline void fsnotify_link_count(struct inode *inode)
{
- fsnotify(inode, FS_ATTRIB, inode, FSNOTIFY_EVENT_INODE, NULL, 0);
+ fsnotify(inode, FS_ATTRIB, inode, FSNOTIFY_EVENT_INODE, NULL, 0, NULL);
}
/*
@@ -102,14 +104,17 @@ static inline void fsnotify_move(struct inode *old_dir, struct inode *new_dir,
new_dir_mask |= FS_ISDIR;
}
- fsnotify(old_dir, old_dir_mask, old_dir, FSNOTIFY_EVENT_INODE, old_name, fs_cookie);
- fsnotify(new_dir, new_dir_mask, new_dir, FSNOTIFY_EVENT_INODE, new_name, fs_cookie);
+ fsnotify(old_dir, old_dir_mask, old_dir, FSNOTIFY_EVENT_INODE,
+ old_name, fs_cookie, NULL);
+ fsnotify(new_dir, new_dir_mask, new_dir, FSNOTIFY_EVENT_INODE,
+ new_name, fs_cookie, NULL);
if (target)
fsnotify_link_count(target);
if (source)
- fsnotify(source, FS_MOVE_SELF, moved->d_inode, FSNOTIFY_EVENT_INODE, NULL, 0);
+ fsnotify(source, FS_MOVE_SELF, moved->d_inode, FSNOTIFY_EVENT_INODE,
+ NULL, 0, NULL);
audit_inode_child(moved, new_dir);
}
@@ -139,7 +144,7 @@ static inline void fsnotify_nameremove(struct dentry *dentry, int isdir)
if (isdir)
mask |= FS_ISDIR;
- fsnotify_parent(NULL, dentry, mask);
+ fsnotify_parent(NULL, dentry, mask, NULL);
}
/*
@@ -147,7 +152,7 @@ static inline void fsnotify_nameremove(struct dentry *dentry, int isdir)
*/
static inline void fsnotify_inoderemove(struct inode *inode)
{
- fsnotify(inode, FS_DELETE_SELF, inode, FSNOTIFY_EVENT_INODE, NULL, 0);
+ fsnotify(inode, FS_DELETE_SELF, inode, FSNOTIFY_EVENT_INODE, NULL, 0, NULL);
__fsnotify_inode_delete(inode);
}
@@ -158,7 +163,8 @@ static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
{
audit_inode_child(dentry, inode);
- fsnotify(inode, FS_CREATE, dentry->d_inode, FSNOTIFY_EVENT_INODE, dentry->d_name.name, 0);
+ fsnotify(inode, FS_CREATE, dentry->d_inode, FSNOTIFY_EVENT_INODE,
+ dentry->d_name.name, 0, NULL);
}
/*
@@ -171,7 +177,8 @@ static inline void fsnotify_link(struct inode *dir, struct inode *inode, struct
fsnotify_link_count(inode);
audit_inode_child(new_dentry, dir);
- fsnotify(dir, FS_CREATE, inode, FSNOTIFY_EVENT_INODE, new_dentry->d_name.name, 0);
+ fsnotify(dir, FS_CREATE, inode, FSNOTIFY_EVENT_INODE,
+ new_dentry->d_name.name, 0, NULL);
}
/*
@@ -184,7 +191,8 @@ static inline void fsnotify_mkdir(struct inode *inode, struct dentry *dentry)
audit_inode_child(dentry, inode);
- fsnotify(inode, mask, d_inode, FSNOTIFY_EVENT_INODE, dentry->d_name.name, 0);
+ fsnotify(inode, mask, d_inode, FSNOTIFY_EVENT_INODE,
+ dentry->d_name.name, 0, NULL);
}
/*
@@ -200,26 +208,33 @@ static inline void fsnotify_access(struct file *file)
mask |= FS_ISDIR;
if (!(file->f_mode & FMODE_NONOTIFY)) {
- fsnotify_parent(path, NULL, mask);
- fsnotify(inode, mask, path, FSNOTIFY_EVENT_PATH, NULL, 0);
+ fsnotify_parent(path, NULL, mask, NULL);
+ fsnotify(inode, mask, path, FSNOTIFY_EVENT_PATH, NULL, 0, NULL);
}
}
+
+
/*
* fsnotify_modify - file was modified
*/
-static inline void fsnotify_modify(struct file *file)
+static inline void fsnotify_modify(struct file *file, loff_t original, size_t count)
{
struct path *path = &file->f_path;
struct inode *inode = path->dentry->d_inode;
__u32 mask = FS_MODIFY;
+ struct fsnotify_range range = {
+ .start = original,
+ .end = original + count,
+ };
+ fsnotify_update_range(&file->f_whatchanged, &range);
if (S_ISDIR(inode->i_mode))
mask |= FS_ISDIR;
if (!(file->f_mode & FMODE_NONOTIFY)) {
- fsnotify_parent(path, NULL, mask);
- fsnotify(inode, mask, path, FSNOTIFY_EVENT_PATH, NULL, 0);
+ fsnotify_parent(path, NULL, mask, &range);
+ fsnotify(inode, mask, path, FSNOTIFY_EVENT_PATH, NULL, 0, &range);
}
}
@@ -238,8 +253,8 @@ static inline void fsnotify_open(struct file *file)
/* FMODE_NONOTIFY must never be set from user */
file->f_mode &= ~FMODE_NONOTIFY;
- fsnotify_parent(path, NULL, mask);
- fsnotify(inode, mask, path, FSNOTIFY_EVENT_PATH, NULL, 0);
+ fsnotify_parent(path, NULL, mask, NULL);
+ fsnotify(inode, mask, path, FSNOTIFY_EVENT_PATH, NULL, 0, NULL);
}
/*
@@ -256,8 +271,9 @@ static inline void fsnotify_close(struct file *file)
mask |= FS_ISDIR;
if (!(file->f_mode & FMODE_NONOTIFY)) {
- fsnotify_parent(path, NULL, mask);
- fsnotify(inode, mask, path, FSNOTIFY_EVENT_PATH, NULL, 0);
+ fsnotify_parent(path, NULL, mask, &file->f_whatchanged);
+ fsnotify(inode, mask, path, FSNOTIFY_EVENT_PATH,
+ NULL, 0, &file->f_whatchanged);
}
}
@@ -272,8 +288,8 @@ static inline void fsnotify_xattr(struct dentry *dentry)
if (S_ISDIR(inode->i_mode))
mask |= FS_ISDIR;
- fsnotify_parent(NULL, dentry, mask);
- fsnotify(inode, mask, inode, FSNOTIFY_EVENT_INODE, NULL, 0);
+ fsnotify_parent(NULL, dentry, mask, NULL);
+ fsnotify(inode, mask, inode, FSNOTIFY_EVENT_INODE, NULL, 0, NULL);
}
/*
@@ -307,8 +323,8 @@ static inline void fsnotify_change(struct dentry *dentry, unsigned int ia_valid)
if (S_ISDIR(inode->i_mode))
mask |= FS_ISDIR;
- fsnotify_parent(NULL, dentry, mask);
- fsnotify(inode, mask, inode, FSNOTIFY_EVENT_INODE, NULL, 0);
+ fsnotify_parent(NULL, dentry, mask, NULL);
+ fsnotify(inode, mask, inode, FSNOTIFY_EVENT_INODE, NULL, 0, NULL);
}
}
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH 3/4] fsnotify: Handle the file change ranges
2010-11-22 0:31 [PATCH 0/4] Series short description Alexey Zaytsev
2010-11-22 0:33 ` [PATCH 1/4] fanotify: Shrink struct fanotify_event_metadata by 32 bits Alexey Zaytsev
2010-11-22 0:33 ` [PATCH 2/4] VFS: Tell fsnotify what part of the file might have changed Alexey Zaytsev
@ 2010-11-22 0:33 ` Alexey Zaytsev
2010-11-22 0:37 ` [PATCH 4/4] fanotify: Expose the file changes to the user Alexey Zaytsev
3 siblings, 0 replies; 32+ messages in thread
From: Alexey Zaytsev @ 2010-11-22 0:33 UTC (permalink / raw)
To: Eric Paris
Cc: Scott Hassan, Jan Kara, agruen, linux-kernel, stefan, Al Viro,
linux-fsdevel, Tvrtko Ursulin
Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>
---
fs/notify/fsnotify.c | 24 ++++++++++++++----------
fs/notify/inode_mark.c | 2 +-
fs/notify/inotify/inotify_user.c | 2 +-
fs/notify/notification.c | 18 ++++++++++++++++--
include/linux/fsnotify_backend.h | 31 ++++++++++++++++++++++++++-----
5 files changed, 58 insertions(+), 19 deletions(-)
diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c
index 20dc218..7cabc1d 100644
--- a/fs/notify/fsnotify.c
+++ b/fs/notify/fsnotify.c
@@ -84,7 +84,8 @@ void __fsnotify_update_child_dentry_flags(struct inode *inode)
}
/* Notify this dentry's parent about a child's events. */
-int __fsnotify_parent(struct path *path, struct dentry *dentry, __u32 mask)
+int __fsnotify_parent(struct path *path, struct dentry *dentry,
+ __u32 mask, struct fsnotify_range *range)
{
struct dentry *parent;
struct inode *p_inode;
@@ -108,10 +109,10 @@ int __fsnotify_parent(struct path *path, struct dentry *dentry, __u32 mask)
if (path)
ret = fsnotify(p_inode, mask, path, FSNOTIFY_EVENT_PATH,
- dentry->d_name.name, 0);
+ dentry->d_name.name, 0, range);
else
ret = fsnotify(p_inode, mask, dentry->d_inode, FSNOTIFY_EVENT_INODE,
- dentry->d_name.name, 0);
+ dentry->d_name.name, 0, range);
}
dput(parent);
@@ -126,6 +127,7 @@ static int send_to_group(struct inode *to_tell, struct vfsmount *mnt,
__u32 mask, void *data,
int data_is, u32 cookie,
const unsigned char *file_name,
+ struct fsnotify_range *range,
struct fsnotify_event **event)
{
struct fsnotify_group *group = NULL;
@@ -167,10 +169,11 @@ static int send_to_group(struct inode *to_tell, struct vfsmount *mnt,
pr_debug("%s: group=%p to_tell=%p mnt=%p mask=%x inode_mark=%p"
" inode_test_mask=%x vfsmount_mark=%p vfsmount_test_mask=%x"
- " data=%p data_is=%d cookie=%d event=%p\n",
+ " data=%p data_is=%d cookie=%d range = {%lld, %lld}, event=%p\n",
__func__, group, to_tell, mnt, mask, inode_mark,
inode_test_mask, vfsmount_mark, vfsmount_test_mask, data,
- data_is, cookie, *event);
+ data_is, cookie, range ? range->start : -1,
+ range ? range->end : -1, *event);
if (!inode_test_mask && !vfsmount_test_mask)
return 0;
@@ -183,7 +186,7 @@ static int send_to_group(struct inode *to_tell, struct vfsmount *mnt,
if (!*event) {
*event = fsnotify_create_event(to_tell, mask, data,
data_is, file_name,
- cookie, GFP_KERNEL);
+ cookie, range, GFP_KERNEL);
if (!*event)
return -ENOMEM;
}
@@ -197,7 +200,8 @@ static int send_to_group(struct inode *to_tell, struct vfsmount *mnt,
* notification event in whatever means they feel necessary.
*/
int fsnotify(struct inode *to_tell, __u32 mask, void *data, int data_is,
- const unsigned char *file_name, u32 cookie)
+ const unsigned char *file_name, u32 cookie,
+ struct fsnotify_range *range)
{
struct hlist_node *inode_node = NULL, *vfsmount_node = NULL;
struct fsnotify_mark *inode_mark = NULL, *vfsmount_mark = NULL;
@@ -256,17 +260,17 @@ int fsnotify(struct inode *to_tell, __u32 mask, void *data, int data_is,
if (inode_group > vfsmount_group) {
/* handle inode */
ret = send_to_group(to_tell, NULL, inode_mark, NULL, mask, data,
- data_is, cookie, file_name, &event);
+ data_is, cookie, file_name, range, &event);
/* we didn't use the vfsmount_mark */
vfsmount_group = NULL;
} else if (vfsmount_group > inode_group) {
ret = send_to_group(to_tell, mnt, NULL, vfsmount_mark, mask, data,
- data_is, cookie, file_name, &event);
+ data_is, cookie, file_name, range, &event);
inode_group = NULL;
} else {
ret = send_to_group(to_tell, mnt, inode_mark, vfsmount_mark,
mask, data, data_is, cookie, file_name,
- &event);
+ range, &event);
}
if (ret && (mask & ALL_FSNOTIFY_PERM_EVENTS))
diff --git a/fs/notify/inode_mark.c b/fs/notify/inode_mark.c
index 4c29fcf..cd39df7 100644
--- a/fs/notify/inode_mark.c
+++ b/fs/notify/inode_mark.c
@@ -295,7 +295,7 @@ void fsnotify_unmount_inodes(struct list_head *list)
iput(need_iput_tmp);
/* for each watch, send FS_UNMOUNT and then remove it */
- fsnotify(inode, FS_UNMOUNT, inode, FSNOTIFY_EVENT_INODE, NULL, 0);
+ fsnotify(inode, FS_UNMOUNT, inode, FSNOTIFY_EVENT_INODE, NULL, 0, NULL);
fsnotify_inode_delete(inode);
diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
index 444c305..a5c2c69 100644
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@ -524,7 +524,7 @@ void inotify_ignored_and_remove_idr(struct fsnotify_mark *fsn_mark,
ignored_event = fsnotify_create_event(NULL, FS_IN_IGNORED, NULL,
FSNOTIFY_EVENT_NONE, NULL, 0,
- GFP_NOFS);
+ NULL, GFP_NOFS);
if (!ignored_event)
return;
diff --git a/fs/notify/notification.c b/fs/notify/notification.c
index f39260f..20b86a0 100644
--- a/fs/notify/notification.c
+++ b/fs/notify/notification.c
@@ -395,7 +395,8 @@ struct fsnotify_event *fsnotify_clone_event(struct fsnotify_event *old_event)
*/
struct fsnotify_event *fsnotify_create_event(struct inode *to_tell, __u32 mask, void *data,
int data_type, const unsigned char *name,
- u32 cookie, gfp_t gfp)
+ u32 cookie, struct fsnotify_range *range,
+ gfp_t gfp)
{
struct fsnotify_event *event;
@@ -422,6 +423,19 @@ struct fsnotify_event *fsnotify_create_event(struct inode *to_tell, __u32 mask,
event->to_tell = to_tell;
event->data_type = data_type;
+ /* The range might be allocated on stack. */
+ if (mask & FS_MODIFY) {
+ event->mod_range = *range;
+ } else {
+ event->mod_range.start = -1;
+ }
+
+ if (mask & FS_CLOSE_WRITE) {
+ event->cw_range = *range;
+ } else {
+ event->cw_range.start = -1;
+ }
+
switch (data_type) {
case FSNOTIFY_EVENT_PATH: {
struct path *path = data;
@@ -453,7 +467,7 @@ __init int fsnotify_notification_init(void)
fsnotify_event_holder_cachep = KMEM_CACHE(fsnotify_event_holder, SLAB_PANIC);
q_overflow_event = fsnotify_create_event(NULL, FS_Q_OVERFLOW, NULL,
- FSNOTIFY_EVENT_NONE, NULL, 0,
+ FSNOTIFY_EVENT_NONE, NULL, 0, NULL,
GFP_KERNEL);
if (!q_overflow_event)
panic("unable to allocate fsnotify q_overflow_event\n");
diff --git a/include/linux/fsnotify_backend.h b/include/linux/fsnotify_backend.h
index 0a68f92..63237c5 100644
--- a/include/linux/fsnotify_backend.h
+++ b/include/linux/fsnotify_backend.h
@@ -240,6 +240,9 @@ struct fsnotify_event {
size_t name_len;
struct pid *tgid;
+ struct fsnotify_range mod_range; /* What has been modified last time */
+ struct fsnotify_range cw_range; /* What has been modified since the file was opened */
+
#ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS
__u32 response; /* userspace answer to question */
#endif /* CONFIG_FANOTIFY_ACCESS_PERMISSIONS */
@@ -305,8 +308,10 @@ struct fsnotify_mark {
/* main fsnotify call to send events */
extern int fsnotify(struct inode *to_tell, __u32 mask, void *data, int data_is,
- const unsigned char *name, u32 cookie);
-extern int __fsnotify_parent(struct path *path, struct dentry *dentry, __u32 mask);
+ const unsigned char *name, u32 cookie,
+ struct fsnotify_range *range);
+extern int __fsnotify_parent(struct path *path, struct dentry *dentry,
+ __u32 mask, struct fsnotify_range *range);
extern void __fsnotify_inode_delete(struct inode *inode);
extern void __fsnotify_vfsmount_delete(struct vfsmount *mnt);
extern u32 fsnotify_get_cookie(void);
@@ -420,22 +425,34 @@ extern void fsnotify_unmount_inodes(struct list_head *list);
extern struct fsnotify_event *fsnotify_create_event(struct inode *to_tell, __u32 mask,
void *data, int data_is,
const unsigned char *name,
- u32 cookie, gfp_t gfp);
+ u32 cookie,
+ struct fsnotify_range *range,
+ gfp_t gfp);
/* fanotify likes to change events after they are on lists... */
extern struct fsnotify_event *fsnotify_clone_event(struct fsnotify_event *old_event);
extern int fsnotify_replace_event(struct fsnotify_event_holder *old_holder,
struct fsnotify_event *new_event);
+static inline void fsnotify_update_range(struct fsnotify_range *new,
+ struct fsnotify_range *old)
+{
+ /* Cast because an empty range starts at -1. */
+ new->start = min((unsigned long long) old->start, (unsigned long long) new->start);
+ new->end = max(old->end, new->end);
+}
+
#else
static inline int fsnotify(struct inode *to_tell, __u32 mask, void *data, int data_is,
- const unsigned char *name, u32 cookie)
+ const unsigned char *name, u32 cookie,
+ struct fsnotify_range *range)
{
return 0;
}
-static inline int __fsnotify_parent(struct path *path, struct dentry *dentry, __u32 mask)
+static inline int __fsnotify_parent(struct path *path, struct dentry *dentry,
+ __u32 mask, struct fsnotify_range *range)
{
return 0;
}
@@ -460,6 +477,10 @@ static inline u32 fsnotify_get_cookie(void)
static inline void fsnotify_unmount_inodes(struct list_head *list)
{}
+static inline void fsnotify_update_range(struct fsnotify_range *new,
+ struct fsnotify_range *old)
+{}
+
#endif /* CONFIG_FSNOTIFY */
#endif /* __KERNEL __ */
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH 4/4] fanotify: Expose the file changes to the user
2010-11-22 0:31 [PATCH 0/4] Series short description Alexey Zaytsev
` (2 preceding siblings ...)
2010-11-22 0:33 ` [PATCH 3/4] fsnotify: Handle the file change ranges Alexey Zaytsev
@ 2010-11-22 0:37 ` Alexey Zaytsev
2010-11-26 10:11 ` Tvrtko Ursulin
3 siblings, 1 reply; 32+ messages in thread
From: Alexey Zaytsev @ 2010-11-22 0:37 UTC (permalink / raw)
To: Eric Paris
Cc: Scott Hassan, Jan Kara, agruen, linux-kernel, stefan, Al Viro,
linux-fsdevel, Tvrtko Ursulin
And revamp the event passing interface in the process.
Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>
---
fs/notify/fanotify/fanotify.c | 19 +++++
fs/notify/fanotify/fanotify_user.c | 132 +++++++++++++++++++++++++++++++-----
include/linux/fanotify.h | 85 ++++++++++++++++++++---
3 files changed, 206 insertions(+), 30 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index b04f88e..1dced4f 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -53,9 +53,15 @@ static struct fsnotify_event *fanotify_merge(struct list_head *list,
fsnotify_get_event(test_event);
- /* if they are exactly the same we are done */
- if (test_event->mask == event->mask)
+
+ /*
+ * Event masks are the same, and the event does not
+ * carry any optional data
+ */
+ if (test_event->mask == event->mask &&
+ !(event->mask & (FS_MODIFY | FS_CLOSE_WRITE))) {
return test_event;
+ }
/*
* if the refcnt == 2 this is the only queue
@@ -64,6 +70,13 @@ static struct fsnotify_event *fanotify_merge(struct list_head *list,
*/
if (atomic_read(&test_event->refcnt) == 2) {
test_event->mask |= event->mask;
+ /*
+ * Update the event's ranges, works even if
+ * the event does not carry any ranges, so don't
+ * bother checking.
+ */
+ fsnotify_update_range(&test_event->mod_range, &event->mod_range);
+ fsnotify_update_range(&test_event->cw_range, &event->cw_range);
return test_event;
}
@@ -78,6 +91,8 @@ static struct fsnotify_event *fanotify_merge(struct list_head *list,
/* build new event and replace it on the list */
new_event->mask = (test_event->mask | event->mask);
+ fsnotify_update_range(&new_event->mod_range, &event->mod_range);
+ fsnotify_update_range(&new_event->cw_range, &event->cw_range);
fsnotify_replace_event(test_holder, new_event);
/* we hold a reference on new_event from clone_event */
diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index 0632248..5774552 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -31,6 +31,57 @@ struct fanotify_response_event {
struct fsnotify_event *event;
};
+#ifdef DEBUG
+static inline void dump_event(const char *str, void *buf)
+{
+ struct fanotify_event_metadata *meta = buf;
+ struct fanotify_opt_hdr *tmp;
+
+ pr_debug("%s: event_len=%d vers=%d mask=0x%lld fd=%d pid=%d\n", str,
+ meta->event_len, meta->vers, meta->mask, meta->fd, meta->pid);
+
+ FAN_FOR_EACH_OPTION(meta, tmp) {
+ /* Hope gcc does a good job here. */
+ struct fan_modify_option *m_opt = FAN_OPT_PAYLOAD(tmp);
+ struct fan_close_write_option *cw_opt = FAN_OPT_PAYLOAD(tmp);
+ switch(tmp->type) {
+
+ case FAN_OPT_MODIFY:
+ pr_debug("\tOption: type = %d, len = %d, range {%lld, %lld}\n",
+ tmp->type, tmp->len, m_opt->start, m_opt->end);
+ break;
+
+ case FAN_OPT_CLOSE_WRITE:
+ pr_debug("\tOption: type = %d, len = %d, range {%lld, %lld}\n",
+ tmp->type, tmp->len, cw_opt->start, cw_opt->end);
+ break;
+
+ default:
+ /* Don't forget to add new options here. */
+ WARN_ON_ONCE(1);
+ }
+ }
+}
+#else
+static inline void dump_event(const char *str, void *buf)
+{
+}
+#endif
+
+static inline int fanotify_event_len(struct fsnotify_event *event)
+{
+ int len = sizeof(struct fanotify_event_metadata);
+ u32 mask = event->mask & FAN_ALL_OUTGOING_EVENTS;
+
+ if (mask & FAN_MODIFY)
+ len += (sizeof(struct fanotify_opt_hdr)
+ + sizeof(struct fan_modify_option));
+ if (mask & FAN_CLOSE_WRITE)
+ len += (sizeof(struct fanotify_opt_hdr)
+ + sizeof(struct fan_close_write_option));
+ return len;
+}
+
/*
* Get an fsnotify notification event if one exists and is small
* enough to fit in "count". Return an error pointer if the count
@@ -41,6 +92,7 @@ struct fanotify_response_event {
static struct fsnotify_event *get_one_event(struct fsnotify_group *group,
size_t count)
{
+ struct fsnotify_event *event;
BUG_ON(!mutex_is_locked(&group->notification_mutex));
pr_debug("%s: group=%p count=%zd\n", __func__, group, count);
@@ -48,7 +100,8 @@ static struct fsnotify_event *get_one_event(struct fsnotify_group *group,
if (fsnotify_notify_queue_is_empty(group))
return NULL;
- if (FAN_EVENT_METADATA_LEN > count)
+ event = fsnotify_peek_notify_event(group);
+ if (fanotify_event_len(event) > count)
return ERR_PTR(-EINVAL);
/* held the notification_mutex the whole time, so this is the
@@ -106,20 +159,58 @@ static int create_fd(struct fsnotify_group *group, struct fsnotify_event *event)
return client_fd;
}
-static ssize_t fill_event_metadata(struct fsnotify_group *group,
- struct fanotify_event_metadata *metadata,
+static int fill_event_metadata(struct fsnotify_group *group,
+ char *event_buffer, int len,
struct fsnotify_event *event)
{
- pr_debug("%s: group=%p metadata=%p event=%p\n", __func__,
- group, metadata, event);
+ struct fanotify_event_metadata *meta =
+ (struct fanotify_event_metadata *) event_buffer;
+
+ struct fanotify_opt_hdr *opt_hdr = (struct fanotify_opt_hdr *)(meta + 1);
+ int meta_len = sizeof(struct fanotify_event_metadata);
+
+ pr_debug("%s: group=%p meta=%p event=%p\n", __func__,
+ group, meta, event);
+
+ if (event->mask & FS_MODIFY) {
+ struct fan_modify_option *opt =
+ (struct fan_modify_option *) (opt_hdr + 1);
+ int opt_len = sizeof(struct fanotify_opt_hdr) +
+ sizeof(struct fan_modify_option);
- metadata->event_len = FAN_EVENT_METADATA_LEN;
- metadata->vers = FANOTIFY_METADATA_VERSION;
- metadata->mask = event->mask & FAN_ALL_OUTGOING_EVENTS;
- metadata->pid = pid_vnr(event->tgid);
- metadata->fd = create_fd(group, event);
+ meta_len += opt_len;
+ opt_hdr->type = FAN_OPT_MODIFY;
+ opt_hdr->len = opt_len;
+ opt->start = event->mod_range.start;
+ opt->end = event->mod_range.end;
- return metadata->fd;
+ opt_hdr = (struct fanotify_opt_hdr *) (((char *) opt_hdr) + opt_len);
+ }
+ if (event->mask & FS_CLOSE_WRITE) {
+ struct fan_close_write_option *opt =
+ (struct fan_close_write_option *) (opt_hdr + 1);
+ int opt_len = sizeof(struct fanotify_opt_hdr) +
+ sizeof(struct fan_close_write_option);
+
+ meta_len += opt_len;
+ opt_hdr->type = FAN_OPT_CLOSE_WRITE;
+ opt_hdr->len = opt_len;
+ opt->start = event->cw_range.start;
+ opt->end = event->cw_range.end;
+
+ opt_hdr = (struct fanotify_opt_hdr *) (((char *) opt_hdr) + opt_len);
+ }
+
+ WARN_ON_ONCE(len != meta_len);
+
+ meta->event_len = meta_len;
+ meta->vers = FANOTIFY_METADATA_VERSION;
+ meta->options_offset = sizeof(struct fanotify_event_metadata);
+ meta->mask = event->mask & FAN_ALL_OUTGOING_EVENTS;
+ meta->pid = pid_vnr(event->tgid);
+ meta->fd = create_fd(group, event);
+
+ return meta->fd;
}
#ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS
@@ -248,16 +339,17 @@ static void remove_access_response(struct fsnotify_group *group,
}
#endif
-static ssize_t copy_event_to_user(struct fsnotify_group *group,
+static int copy_event_to_user(struct fsnotify_group *group,
struct fsnotify_event *event,
char __user *buf)
{
- struct fanotify_event_metadata fanotify_event_metadata;
+ int len = fanotify_event_len(event);
+ char fanotify_event_buf[len];
int fd, ret;
pr_debug("%s: group=%p event=%p\n", __func__, group, event);
- fd = fill_event_metadata(group, &fanotify_event_metadata, event);
+ fd = fill_event_metadata(group, fanotify_event_buf, len, event);
if (fd < 0)
return fd;
@@ -266,10 +358,12 @@ static ssize_t copy_event_to_user(struct fsnotify_group *group,
goto out_close_fd;
ret = -EFAULT;
- if (copy_to_user(buf, &fanotify_event_metadata, FAN_EVENT_METADATA_LEN))
+ if (copy_to_user(buf, fanotify_event_buf, len))
goto out_kill_access_response;
- return FAN_EVENT_METADATA_LEN;
+ dump_event(__func__, fanotify_event_buf);
+
+ return len;
out_kill_access_response:
remove_access_response(group, event, fd);
@@ -418,8 +512,10 @@ static long fanotify_ioctl(struct file *file, unsigned int cmd, unsigned long ar
switch (cmd) {
case FIONREAD:
mutex_lock(&group->notification_mutex);
- list_for_each_entry(holder, &group->notification_list, event_list)
- send_len += FAN_EVENT_METADATA_LEN;
+ list_for_each_entry(holder, &group->notification_list, event_list) {
+ struct fsnotify_event *event = holder->event;
+ send_len += fanotify_event_len(event);
+ }
mutex_unlock(&group->notification_mutex);
ret = put_user(send_len, (int __user *) p);
break;
diff --git a/include/linux/fanotify.h b/include/linux/fanotify.h
index 9a7986f..87dfe36 100644
--- a/include/linux/fanotify.h
+++ b/include/linux/fanotify.h
@@ -83,17 +83,50 @@
FAN_ALL_PERM_EVENTS |\
FAN_Q_OVERFLOW)
-#define FANOTIFY_METADATA_VERSION 2
+/* Option types, mirror the event mask, but we can pack them into u8. */
+enum fanotify_opt_type {
+ FAN_OPT_NONE = 0,
+ FAN_OPT_ACCESS,
+ FAN_OPT_MODIFY,
+ FAN_OPT_CLOSE_WRITE,
+ FAN_OPT_CLOSE_NOWRITE,
+ FAN_OPT_OPEN,
+ FAN_OPT_Q_OVERFLOW,
+ FAN_OPT_OPEN_PERM,
+ FAN_OPT_ACCESS_PERM,
+};
+
+struct fanotify_opt_hdr {
+ __u8 type;
+ __u8 reserved;
+ __u16 len;
+ /* Payload goes here. */
+};
+
+#define FANOTIFY_METADATA_VERSION 3
struct fanotify_event_metadata {
- __u16 event_len;
+ __u16 event_len; /* Including the options */
__u8 vers;
- __u8 reserved;
+ __u8 options_offset; /* Aka header length */
__s32 fd;
__aligned_u64 mask;
__s32 pid;
+ /* Options go here. */
};
+struct fan_modify_option {
+ __aligned_u64 start; /* Start of the modification. */
+ __aligned_u64 end; /* The position right after the modification. */
+};
+
+struct fan_close_write_option {
+ __aligned_u64 start; /* Start of the modifications. */
+ __aligned_u64 end; /* The position right after the modifications. */
+};
+
+/* Update fanotify_event_len() when you add more options. */
+
struct fanotify_response {
__s32 fd;
__u32 response;
@@ -103,15 +136,47 @@ struct fanotify_response {
#define FAN_ALLOW 0x01
#define FAN_DENY 0x02
-/* Helper functions to deal with fanotify_event_metadata buffers */
-#define FAN_EVENT_METADATA_LEN (sizeof(struct fanotify_event_metadata))
-
#define FAN_EVENT_NEXT(meta, len) ((len) -= (meta)->event_len, \
(struct fanotify_event_metadata*)(((char *)(meta)) + \
(meta)->event_len))
-#define FAN_EVENT_OK(meta, len) ((long)(len) >= (long)FAN_EVENT_METADATA_LEN && \
- (long)(meta)->event_len >= (long)FAN_EVENT_METADATA_LEN && \
- (long)(meta)->event_len <= (long)(len))
-
+static inline int FAN_EVENT_OK(struct fanotify_event_metadata *meta, size_t len)
+{
+ return (len >= sizeof(struct fanotify_event_metadata) &&
+ meta->event_len >= sizeof(struct fanotify_event_metadata) &&
+ meta->event_len <= len);
+}
+
+#define FAN_FOR_EACH_EVENT(meta, buf, len) \
+ for (meta = (struct fanotify_event_metadata *) buf; \
+ FAN_EVENT_OK(meta, len); \
+ meta = FAN_EVENT_NEXT(meta, len))
+
+
+static inline struct fanotify_opt_hdr *FAN_OPTION_FIRST(
+ struct fanotify_event_metadata *meta)
+{
+ return (struct fanotify_opt_hdr *) (((char *) meta) + meta->options_offset);
+}
+static inline struct fanotify_opt_hdr *FAN_OPTION_NEXT(
+ struct fanotify_opt_hdr *opt)
+{
+ return (struct fanotify_opt_hdr *) (((char *) opt) + opt->len);
+}
+
+static inline int FAN_OPTION_OK(struct fanotify_event_metadata *meta,
+ struct fanotify_opt_hdr *opt)
+{
+ return ((char *) opt) < (((char *)meta) + meta->event_len);
+}
+
+#define FAN_FOR_EACH_OPTION(meta, tmp) \
+ for (tmp = FAN_OPTION_FIRST(meta); \
+ FAN_OPTION_OK(meta, tmp); \
+ tmp = FAN_OPTION_NEXT(tmp))
+
+static inline void *FAN_OPT_PAYLOAD(struct fanotify_opt_hdr *opt)
+{
+ return (opt + 1);
+}
#endif /* _LINUX_FANOTIFY_H */
^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH 1/4] fanotify: Shrink struct fanotify_event_metadata by 32 bits
2010-11-22 0:33 ` [PATCH 1/4] fanotify: Shrink struct fanotify_event_metadata by 32 bits Alexey Zaytsev
@ 2010-11-26 7:01 ` Alexey Zaytsev
0 siblings, 0 replies; 32+ messages in thread
From: Alexey Zaytsev @ 2010-11-26 7:01 UTC (permalink / raw)
To: Eric Paris
Cc: Scott Hassan, Jan Kara, agruen, linux-kernel, stefan, Al Viro,
linux-fsdevel, Tvrtko Ursulin, Linus Torvalds
Hi, Eric. Sorry for the noise, but could you please comment at this
one? Because if it goes, it needs to go soon, before the .37 release,
or we won't be able change the ABI.
The other patches in the series are clearly not .37 material, so no
problem if you can't look at them right now.
On Mon, Nov 22, 2010 at 03:33, Alexey Zaytsev <alexey.zaytsev@gmail.com> wrote:
> And this saves additional 32 bits in the future
>
> Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>
> ---
> include/linux/fanotify.h | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/fanotify.h b/include/linux/fanotify.h
> index 0f01214..9a7986f 100644
> --- a/include/linux/fanotify.h
> +++ b/include/linux/fanotify.h
> @@ -86,10 +86,11 @@
> #define FANOTIFY_METADATA_VERSION 2
>
> struct fanotify_event_metadata {
> - __u32 event_len;
> - __u32 vers;
> - __aligned_u64 mask;
> + __u16 event_len;
> + __u8 vers;
> + __u8 reserved;
> __s32 fd;
> + __aligned_u64 mask;
> __s32 pid;
> };
>
>
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/4] fanotify: Shrink struct fanotify_event_metadata by 32 bits
@ 2010-11-26 7:01 ` Alexey Zaytsev
0 siblings, 0 replies; 32+ messages in thread
From: Alexey Zaytsev @ 2010-11-26 7:01 UTC (permalink / raw)
To: Eric Paris
Cc: Scott Hassan, Jan Kara, agruen, linux-kernel, stefan, Al Viro,
linux-fsdevel, Tvrtko Ursulin, Linus Torvalds
Hi, Eric. Sorry for the noise, but could you please comment at this
one? Because if it goes, it needs to go soon, before the .37 release,
or we won't be able change the ABI.
The other patches in the series are clearly not .37 material, so no
problem if you can't look at them right now.
On Mon, Nov 22, 2010 at 03:33, Alexey Zaytsev <alexey.zaytsev@gmail.com> wrote:
> And this saves additional 32 bits in the future
>
> Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>
> ---
> include/linux/fanotify.h | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/fanotify.h b/include/linux/fanotify.h
> index 0f01214..9a7986f 100644
> --- a/include/linux/fanotify.h
> +++ b/include/linux/fanotify.h
> @@ -86,10 +86,11 @@
> #define FANOTIFY_METADATA_VERSION 2
>
> struct fanotify_event_metadata {
> - __u32 event_len;
> - __u32 vers;
> - __aligned_u64 mask;
> + __u16 event_len;
> + __u8 vers;
> + __u8 reserved;
> __s32 fd;
> + __aligned_u64 mask;
> __s32 pid;
> };
>
>
>
--
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 4/4] fanotify: Expose the file changes to the user
2010-11-22 0:37 ` [PATCH 4/4] fanotify: Expose the file changes to the user Alexey Zaytsev
@ 2010-11-26 10:11 ` Tvrtko Ursulin
2010-11-26 11:21 ` Alexey Zaytsev
2010-11-29 16:14 ` Eric Paris
0 siblings, 2 replies; 32+ messages in thread
From: Tvrtko Ursulin @ 2010-11-26 10:11 UTC (permalink / raw)
To: Alexey Zaytsev
Cc: Eric Paris, Scott Hassan, Jan Kara, agruen, linux-kernel, stefan,
Al Viro, linux-fsdevel
On Monday 22 Nov 2010 00:37:21 Alexey Zaytsev wrote:
> +struct fanotify_opt_hdr {
> + __u8 type;
> + __u8 reserved;
> + __u16 len;
> + /* Payload goes here. */
> +};
> +
> +#define FANOTIFY_METADATA_VERSION 3
>
> struct fanotify_event_metadata {
> - __u16 event_len;
> + __u16 event_len; /* Including the options */
> __u8 vers;
> - __u8 reserved;
> + __u8 options_offset; /* Aka header length */
> __s32 fd;
> __aligned_u64 mask;
> __s32 pid;
> + /* Options go here. */
> };
I am not 100% comfortable with having 16 bits length fields because I am just
not sure there is a measurable performance difference versus just going with
32 bits.
Also, options_offset is, if I understood it correctly, basically the lenght of
fanotify_event_metadata. As such, isn't that field redundant since the lenght
is implied from the protocol version?
For which it follows that maybe no changes to fanotify_event_metadata are
needed to grow the protocol in the future. We have the version and total
lenght. All that is required is that we never change width and position of
version and lenght field and we should be fine. Later we can define option
structures each of which will "point" to the next and thats it, no?
Tvrtko
Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 991 2418 08.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 4/4] fanotify: Expose the file changes to the user
2010-11-26 10:11 ` Tvrtko Ursulin
@ 2010-11-26 11:21 ` Alexey Zaytsev
2010-11-26 11:41 ` Tvrtko Ursulin
2010-11-29 16:14 ` Eric Paris
1 sibling, 1 reply; 32+ messages in thread
From: Alexey Zaytsev @ 2010-11-26 11:21 UTC (permalink / raw)
To: Tvrtko Ursulin
Cc: Eric Paris, Scott Hassan, Jan Kara, agruen, linux-kernel, stefan,
Al Viro, linux-fsdevel
On Fri, Nov 26, 2010 at 13:11, Tvrtko Ursulin <tvrtko.ursulin@sophos.com> wrote:
> On Monday 22 Nov 2010 00:37:21 Alexey Zaytsev wrote:
>> +struct fanotify_opt_hdr {
>> + __u8 type;
>> + __u8 reserved;
>> + __u16 len;
>> + /* Payload goes here. */
>> +};
>> +
>> +#define FANOTIFY_METADATA_VERSION 3
>>
>> struct fanotify_event_metadata {
>> - __u16 event_len;
>> + __u16 event_len; /* Including the options */
>> __u8 vers;
>> - __u8 reserved;
>> + __u8 options_offset; /* Aka header length */
>> __s32 fd;
>> __aligned_u64 mask;
>> __s32 pid;
>> + /* Options go here. */
>> };
>
> I am not 100% comfortable with having 16 bits length fields because I am just
> not sure there is a measurable performance difference versus just going with
> 32 bits.
I'm not concerned so much with the performance, as with the storage.
If we are generating events for every access on a mount point, some
consumers might build a considerable backlog over a period of high
activity. Would be good if we could cut the event size by 1/3 for
free. And I don't see an event growing 64k even with the options. Do
you?
>
> Also, options_offset is, if I understood it correctly, basically the lenght of
> fanotify_event_metadata. As such, isn't that field redundant since the lenght
> is implied from the protocol version?
There are two problems there.
1) You lose backwards-compatibility. It's still an ABI breakage, even
if you tell the users about it.
2) You can't build a program to account for different fanotify versions:
if (vers >= N) { use the cool stuff } else if {vers >= N-1} {
still good }
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 4/4] fanotify: Expose the file changes to the user
2010-11-26 11:21 ` Alexey Zaytsev
@ 2010-11-26 11:41 ` Tvrtko Ursulin
2010-11-26 12:11 ` Alexey Zaytsev
0 siblings, 1 reply; 32+ messages in thread
From: Tvrtko Ursulin @ 2010-11-26 11:41 UTC (permalink / raw)
To: Alexey Zaytsev
Cc: Eric Paris, Scott Hassan, Jan Kara, agruen, linux-kernel, stefan,
Al Viro, linux-fsdevel
On Friday 26 Nov 2010 11:21:18 Alexey Zaytsev wrote:
> On Fri, Nov 26, 2010 at 13:11, Tvrtko Ursulin <tvrtko.ursulin@sophos.com>
wrote:
> > On Monday 22 Nov 2010 00:37:21 Alexey Zaytsev wrote:
> >> +struct fanotify_opt_hdr {
> >> + __u8 type;
> >> + __u8 reserved;
> >> + __u16 len;
> >> + /* Payload goes here. */
> >> +};
> >> +
> >> +#define FANOTIFY_METADATA_VERSION 3
> >>
> >> struct fanotify_event_metadata {
> >> - __u16 event_len;
> >> + __u16 event_len; /* Including the options */
> >> __u8 vers;
> >> - __u8 reserved;
> >> + __u8 options_offset; /* Aka header length */
> >> __s32 fd;
> >> __aligned_u64 mask;
> >> __s32 pid;
> >> + /* Options go here. */
> >> };
> >
> > I am not 100% comfortable with having 16 bits length fields because I am
> > just not sure there is a measurable performance difference versus just
> > going with 32 bits.
>
> I'm not concerned so much with the performance, as with the storage.
> If we are generating events for every access on a mount point, some
> consumers might build a considerable backlog over a period of high
> activity. Would be good if we could cut the event size by 1/3 for
> free. And I don't see an event growing 64k even with the options. Do
> you?
I don't but maybe it is just lack of imagination.
My bias is that I am mostly thinking about synchronous events where large
backlog is not a realistic scenario. How realistic you think is this with
async events?
> > Also, options_offset is, if I understood it correctly, basically the
> > lenght of fanotify_event_metadata. As such, isn't that field redundant
> > since the lenght is implied from the protocol version?
>
> There are two problems there.
>
> 1) You lose backwards-compatibility. It's still an ABI breakage, even
> if you tell the users about it.
Assuming 2.6.37 release as starting point for ABI considerations?
> 2) You can't build a program to account for different fanotify versions:
> if (vers >= N) { use the cool stuff } else if {vers >= N-1} {
> still good }
I don't get why not, but maybe I am just slow today. There will always be 1:1
mapping from version to your options_offset field, no? How does then removing
options_offset change anything?
Tvrtko
Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 991 2418 08.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 4/4] fanotify: Expose the file changes to the user
2010-11-26 11:41 ` Tvrtko Ursulin
@ 2010-11-26 12:11 ` Alexey Zaytsev
0 siblings, 0 replies; 32+ messages in thread
From: Alexey Zaytsev @ 2010-11-26 12:11 UTC (permalink / raw)
To: Tvrtko Ursulin
Cc: Eric Paris, Scott Hassan, Jan Kara, agruen, linux-kernel, stefan,
Al Viro, linux-fsdevel
On Fri, Nov 26, 2010 at 14:41, Tvrtko Ursulin <tvrtko.ursulin@sophos.com> wrote:
> On Friday 26 Nov 2010 11:21:18 Alexey Zaytsev wrote:
>> On Fri, Nov 26, 2010 at 13:11, Tvrtko Ursulin <tvrtko.ursulin@sophos.com>
> wrote:
>> > On Monday 22 Nov 2010 00:37:21 Alexey Zaytsev wrote:
>> >> +struct fanotify_opt_hdr {
>> >> + __u8 type;
>> >> + __u8 reserved;
>> >> + __u16 len;
>> >> + /* Payload goes here. */
>> >> +};
>> >> +
>> >> +#define FANOTIFY_METADATA_VERSION 3
>> >>
>> >> struct fanotify_event_metadata {
>> >> - __u16 event_len;
>> >> + __u16 event_len; /* Including the options */
>> >> __u8 vers;
>> >> - __u8 reserved;
>> >> + __u8 options_offset; /* Aka header length */
>> >> __s32 fd;
>> >> __aligned_u64 mask;
>> >> __s32 pid;
>> >> + /* Options go here. */
>> >> };
>> >
>> > I am not 100% comfortable with having 16 bits length fields because I am
>> > just not sure there is a measurable performance difference versus just
>> > going with 32 bits.
>>
>> I'm not concerned so much with the performance, as with the storage.
>> If we are generating events for every access on a mount point, some
>> consumers might build a considerable backlog over a period of high
>> activity. Would be good if we could cut the event size by 1/3 for
>> free. And I don't see an event growing 64k even with the options. Do
>> you?
>
> I don't but maybe it is just lack of imagination.
>
> My bias is that I am mostly thinking about synchronous events where large
> backlog is not a realistic scenario. How realistic you think is this with
> async events?
>
Ok, you are probably right, we can't build a huge backlog, because
each event carries an open fd with it. So, given the unnoticeable
performance gain, it might be worth the leave the possibility to pass
events greater than 64k (with options) in the future, no matter how
unlikely this looks now. We still could save 32 bit by packing the
vers and the offset together. The common part of the events
(options_offset) should not grow over 256 byte, or it would start to
affect the performance for common events, and I hope that 256 versions
would also be enough, so we could even reserve 16 bit for further
extensions.
Eric?
>> > Also, options_offset is, if I understood it correctly, basically the
>> > lenght of fanotify_event_metadata. As such, isn't that field redundant
>> > since the lenght is implied from the protocol version?
>>
>> There are two problems there.
>>
>> 1) You lose backwards-compatibility. It's still an ABI breakage, even
>> if you tell the users about it.
>
> Assuming 2.6.37 release as starting point for ABI considerations?
Yep, that's why I'm asking to include the first patch into .37.
>
>> 2) You can't build a program to account for different fanotify versions:
>> if (vers >= N) { use the cool stuff } else if {vers >= N-1} {
>> still good }
>
> I don't get why not, but maybe I am just slow today. There will always be 1:1
> mapping from version to your options_offset field, no? How does then removing
> options_offset change anything?
>
You need to get the old version of the ABI definition somewhere. And
if you need to cast the events to different types, and use different
versions of FAN_OPTION* depending on the event version, the program
also becomes a bit complicated.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 4/4] fanotify: Expose the file changes to the user
2010-11-26 10:11 ` Tvrtko Ursulin
2010-11-26 11:21 ` Alexey Zaytsev
@ 2010-11-29 16:14 ` Eric Paris
2010-11-29 16:51 ` Alexey Zaytsev
2010-11-29 17:11 ` Tvrtko Ursulin
1 sibling, 2 replies; 32+ messages in thread
From: Eric Paris @ 2010-11-29 16:14 UTC (permalink / raw)
To: Tvrtko Ursulin
Cc: Alexey Zaytsev, Scott Hassan, Jan Kara, agruen, linux-kernel,
stefan, Al Viro, linux-fsdevel
On Fri, 2010-11-26 at 10:11 +0000, Tvrtko Ursulin wrote:
> On Monday 22 Nov 2010 00:37:21 Alexey Zaytsev wrote:
> > struct fanotify_event_metadata {
> > - __u16 event_len;
> > + __u16 event_len; /* Including the options */
> > __u8 vers;
> > - __u8 reserved;
> > + __u8 options_offset; /* Aka header length */
> > __s32 fd;
> > __aligned_u64 mask;
> > __s32 pid;
> > + /* Options go here. */
> > };
> Also, options_offset is, if I understood it correctly, basically the lenght of
> fanotify_event_metadata. As such, isn't that field redundant since the lenght
> is implied from the protocol version?
Ok, the way I envision the interface is the fanotify_event_metadata is
going to be information that is common for all event types. If a
particular event type (in the case being brought forth MODIFY and
CLOSE_WRITE) needs more information it will use the optional headers.
I'd still like to be able to add generic info, ex: the uid of the
requesting process, to the generic event metadata. We might also
someday want to use the optional headers for things like the inotify
move cookie. Why waste space in every event when only the move type
events cared about this cookie?
This necessitates options_offset. Lets say I compile my userspace app
as version 3. I know that fanotify_event_metadata is 14 bytes long in
version 3. Thus I start looking at byte 15 for the first optional
header. But the kernel is version 4 and fanotify_event_metadata is
actually 18 bytes long. Whoops, userspace should be looking at byte 19
for the header but accidentally looked at byte 15. options_offset will
allow a version 3 userspace to run on a version 4 kernel while skipping
bytes 15-18 which it doesn't understand.
At the end of all of this discussion what did people finally agree on?
Something like this?
struct fanotify_opt_hdr {
__u16 type;
__u16 len;
/* Payload goes here. */
};
struct fanotify_event_metadata {
__u32 event_len; /* Including the options */
__u16 vers;
__u16 options_offset; /* Aka header length */
__s32 fd;
__aligned_u64 mask;
__s32 pid;
/* Options go here. */
};
We could be ABI compatible if we let vers as a __u32 and added
options_offset at the end of the structure... Do we have strong
feelings on either side about maintaining compatibility or about
structure lengths?
-Eric
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 4/4] fanotify: Expose the file changes to the user
2010-11-29 16:14 ` Eric Paris
@ 2010-11-29 16:51 ` Alexey Zaytsev
2010-11-29 18:14 ` Eric Paris
2010-11-29 17:11 ` Tvrtko Ursulin
1 sibling, 1 reply; 32+ messages in thread
From: Alexey Zaytsev @ 2010-11-29 16:51 UTC (permalink / raw)
To: Eric Paris
Cc: Tvrtko Ursulin, Scott Hassan, Jan Kara, agruen, linux-kernel,
stefan, Al Viro, linux-fsdevel
On Mon, Nov 29, 2010 at 19:14, Eric Paris <eparis@redhat.com> wrote:
> On Fri, 2010-11-26 at 10:11 +0000, Tvrtko Ursulin wrote:
>> On Monday 22 Nov 2010 00:37:21 Alexey Zaytsev wrote:
>
>> > struct fanotify_event_metadata {
>> > - __u16 event_len;
>> > + __u16 event_len; /* Including the options */
>> > __u8 vers;
>> > - __u8 reserved;
>> > + __u8 options_offset; /* Aka header length */
>> > __s32 fd;
>> > __aligned_u64 mask;
>> > __s32 pid;
>> > + /* Options go here. */
>> > };
>
>> Also, options_offset is, if I understood it correctly, basically the lenght of
>> fanotify_event_metadata. As such, isn't that field redundant since the lenght
>> is implied from the protocol version?
>
> Ok, the way I envision the interface is the fanotify_event_metadata is
> going to be information that is common for all event types. If a
> particular event type (in the case being brought forth MODIFY and
> CLOSE_WRITE) needs more information it will use the optional headers.
> I'd still like to be able to add generic info, ex: the uid of the
> requesting process, to the generic event metadata. We might also
> someday want to use the optional headers for things like the inotify
> move cookie. Why waste space in every event when only the move type
> events cared about this cookie?
>
> This necessitates options_offset. Lets say I compile my userspace app
> as version 3. I know that fanotify_event_metadata is 14 bytes long in
> version 3. Thus I start looking at byte 15 for the first optional
> header. But the kernel is version 4 and fanotify_event_metadata is
> actually 18 bytes long. Whoops, userspace should be looking at byte 19
> for the header but accidentally looked at byte 15. options_offset will
> allow a version 3 userspace to run on a version 4 kernel while skipping
> bytes 15-18 which it doesn't understand.
>
> At the end of all of this discussion what did people finally agree on?
> Something like this?
>
> struct fanotify_opt_hdr {
> __u16 type;
> __u16 len;
> /* Payload goes here. */
> };
>
> struct fanotify_event_metadata {
> __u32 event_len; /* Including the options */
> __u16 vers;
> __u16 options_offset; /* Aka header length */
> __s32 fd;
> __aligned_u64 mask;
> __s32 pid;
> /* Options go here. */
> };
>
Yep, except mask should go after options_offset to avoid the gap, and
let's make both vers and options_offset u8, just in case we need the
other 2 bytes in the future:
struct fanotify_event_metadata {
__u32 event_len; /* Including the options */
__u8 vers;
__u8 options_offset; /* Aka header length */
__u16 reserved;
__aligned_u64 mask;
__s32 fd;
__s32 pid;
/* Options go here. */
};
> We could be ABI compatible if we let vers as a __u32 and added
> options_offset at the end of the structure... Do we have strong
> feelings on either side about maintaining compatibility or about3
> structure lengths?
Actually, with event_len being __u32, and mask moved back, we are
already abi-compatible. The users would see the wrong version, but
it's always > 2, so everyone happy. Together with the hypothetical
huge options, this fully justifies spending 2 bytes on event_len to
me.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 4/4] fanotify: Expose the file changes to the user
2010-11-29 16:14 ` Eric Paris
2010-11-29 16:51 ` Alexey Zaytsev
@ 2010-11-29 17:11 ` Tvrtko Ursulin
1 sibling, 0 replies; 32+ messages in thread
From: Tvrtko Ursulin @ 2010-11-29 17:11 UTC (permalink / raw)
To: Eric Paris
Cc: Alexey Zaytsev, Scott Hassan, Jan Kara, agruen, linux-kernel,
stefan, Al Viro, linux-fsdevel
On Monday 29 Nov 2010 16:14:54 Eric Paris wrote:
> On Fri, 2010-11-26 at 10:11 +0000, Tvrtko Ursulin wrote:
> > On Monday 22 Nov 2010 00:37:21 Alexey Zaytsev wrote:
> > > struct fanotify_event_metadata {
> > >
> > > - __u16 event_len;
> > > + __u16 event_len; /* Including the options */
> > >
> > > __u8 vers;
> > >
> > > - __u8 reserved;
> > > + __u8 options_offset; /* Aka header length */
> > >
> > > __s32 fd;
> > > __aligned_u64 mask;
> > > __s32 pid;
> > >
> > > + /* Options go here. */
> > >
> > > };
> >
> > Also, options_offset is, if I understood it correctly, basically the
> > lenght of fanotify_event_metadata. As such, isn't that field redundant
> > since the lenght is implied from the protocol version?
>
> Ok, the way I envision the interface is the fanotify_event_metadata is
> going to be information that is common for all event types. If a
> particular event type (in the case being brought forth MODIFY and
> CLOSE_WRITE) needs more information it will use the optional headers.
> I'd still like to be able to add generic info, ex: the uid of the
> requesting process, to the generic event metadata. We might also
> someday want to use the optional headers for things like the inotify
> move cookie. Why waste space in every event when only the move type
> events cared about this cookie?
>
> This necessitates options_offset. Lets say I compile my userspace app
> as version 3. I know that fanotify_event_metadata is 14 bytes long in
> version 3. Thus I start looking at byte 15 for the first optional
> header. But the kernel is version 4 and fanotify_event_metadata is
> actually 18 bytes long. Whoops, userspace should be looking at byte 19
> for the header but accidentally looked at byte 15. options_offset will
> allow a version 3 userspace to run on a version 4 kernel while skipping
> bytes 15-18 which it doesn't understand.
I see now what you want to do here. I assumed metadata is fixed for ever and
all expansions will come via options. That is why I said offset field is
redundant. If you want to leave option for changing metadata open then yes, I
agree it is needed.
> At the end of all of this discussion what did people finally agree on?
> Something like this?
>
> struct fanotify_opt_hdr {
> __u16 type;
> __u16 len;
> /* Payload goes here. */
> };
>
> struct fanotify_event_metadata {
> __u32 event_len; /* Including the options */
> __u16 vers;
> __u16 options_offset; /* Aka header length */
> __s32 fd;
> __aligned_u64 mask;
> __s32 pid;
> /* Options go here. */
> };
>
> We could be ABI compatible if we let vers as a __u32 and added
> options_offset at the end of the structure... Do we have strong
> feelings on either side about maintaining compatibility or about
> structure lengths?
No strong feelings here on either. I do not really think maintaining
compatibility with an unreleased protocol is worth it. And I would not like to
limit any field to 8-bits if possible.
Tvrtko
Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 991 2418 08.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 4/4] fanotify: Expose the file changes to the user
2010-11-29 16:51 ` Alexey Zaytsev
@ 2010-11-29 18:14 ` Eric Paris
0 siblings, 0 replies; 32+ messages in thread
From: Eric Paris @ 2010-11-29 18:14 UTC (permalink / raw)
To: Alexey Zaytsev
Cc: Tvrtko Ursulin, Scott Hassan, Jan Kara, agruen, linux-kernel,
stefan, Al Viro, linux-fsdevel
On Mon, 2010-11-29 at 19:51 +0300, Alexey Zaytsev wrote:
[rewriting history!]
> struct fanotify_event_metadata {
> __u32 event_len; /* Including the options */
> __u8 vers;
> __u8 options_offset; /* Aka header length */
> __u16 reserved;
> __aligned_u64 mask;
> __s32 fd;
> __s32 pid;
> /* Options go here. */
> };
> and let's make both vers and options_offset u8, just in case we need the
> other 2 bytes in the future:
So the last discussion is around vers and options_offset.
Alexy: Tvrtko:
__u8 vers; __u16 vers;
__u8 options_offset; __u16 options_offset;
__u16 unused;
The only type of long option that first comes to mind is a filename. A
filename could easily blow out the __u8 options_offset. I probably
shouldn't put that in the event_metadata since it wouldn't be fixed
length and it wouldn't allow fixed offset extention of the
event_metadata, so maybe I shouldn't worry about it. I'm trying to
think of reasons why __u8 isn't adequate other than my usual "just make
it bigger than we ever need"
You'll notice I'm using __u64 for the mask, even though we don't come
close to filling up an __u32 at this point.
Even though I can't think of a likely reason __u8 is bad I think I like
the 'Tvrtko' option better. I think we should do a compromise:
Eric:
__u8 vers;
__u8 unused;
__u16 options_offset;
If we ever overload vers we can expand into another field. Would could
change unused into vers2 and define the version as vers + vers2; vers2
could even exist somewhere else in the metadata. That can be done once
we get to version 254 while maintaining backwards compat beyond 255. If
we ever overflow options_offset we are screwed since old userspace
wouldn't know how to handle things.
So, if you want to send me a patch that implements the above (along with
the obvious version bump to 3, I'll queue it up for this merge window
even though we have an ABI compatible solution.
-Eric
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 0/4] Series short description
@ 2012-09-01 0:26 ` Tony Lindgren
0 siblings, 0 replies; 32+ messages in thread
From: Tony Lindgren @ 2012-09-01 0:26 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: linux-omap
Hi all,
Here are the changes needed to make hardware.h local for mach-omap2.
These patches are based on v3.6-rc3 and the following patches:
- Arnd's patch "ARM: omap: move platform_data definitions"
- Igor's series "ARM: OMAP: cleanup plat/board.h file"
- Afzal's series "Prepare for GPMC driver conversion (w.r.t MTD)"
- My series "Clean up hardcoded IRQs for mach-omap2, enable SPARSE_IRQ,
plaform_data/gpio-omap.h"
Regards,
Tony
---
Tony Lindgren (4):
ARM: OMAP: Remove unused old gpio-switch.h
ARM: OMAP: Split plat/hardware.h, introduce local hardware.h and soc.h for omap2+
ARM: OMAP2+ Move SoC specific headers to be local to mach-omap2
ARM: OMAP1: Move SoC specific headers from plat to mach for omap1
arch/arm/mach-omap1/board-htcherald.c | 4
arch/arm/mach-omap1/devices.c | 2
arch/arm/mach-omap1/include/mach/hardware.h | 285 +++++++++++++++++++++++
arch/arm/mach-omap1/include/mach/omap1510.h | 3
arch/arm/mach-omap1/include/mach/omap16xx.h | 3
arch/arm/mach-omap1/include/mach/omap7xx.h | 3
arch/arm/mach-omap2/am33xx.h | 0
arch/arm/mach-omap2/board-2430sdp.c | 2
arch/arm/mach-omap2/board-3430sdp.c | 9 -
arch/arm/mach-omap2/board-4430sdp.c | 9 -
arch/arm/mach-omap2/board-am3517crane.c | 1
arch/arm/mach-omap2/board-am3517evm.c | 1
arch/arm/mach-omap2/board-apollon.c | 3
arch/arm/mach-omap2/board-cm-t35.c | 2
arch/arm/mach-omap2/board-cm-t3517.c | 3
arch/arm/mach-omap2/board-devkit8000.c | 22 +-
arch/arm/mach-omap2/board-flash.c | 6
arch/arm/mach-omap2/board-generic.c | 1
arch/arm/mach-omap2/board-h4.c | 3
arch/arm/mach-omap2/board-igep0020.c | 1
arch/arm/mach-omap2/board-ldp.c | 10 -
arch/arm/mach-omap2/board-n8x0.c | 10 -
arch/arm/mach-omap2/board-omap3beagle.c | 12 -
arch/arm/mach-omap2/board-omap3evm.c | 11 -
arch/arm/mach-omap2/board-omap3logic.c | 16 -
arch/arm/mach-omap2/board-omap3pandora.c | 9 -
arch/arm/mach-omap2/board-omap3stalker.c | 20 +-
arch/arm/mach-omap2/board-omap3touchbook.c | 9 -
arch/arm/mach-omap2/board-omap4panda.c | 7 -
arch/arm/mach-omap2/board-overo.c | 14 -
arch/arm/mach-omap2/board-rm680.c | 1
arch/arm/mach-omap2/board-rx51.c | 5
arch/arm/mach-omap2/board-ti8168evm.c | 2
arch/arm/mach-omap2/board-zoom-debugboard.c | 4
arch/arm/mach-omap2/board-zoom-display.c | 4
arch/arm/mach-omap2/board-zoom-peripherals.c | 1
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 2
arch/arm/mach-omap2/clkt_dpll.c | 2
arch/arm/mach-omap2/clock.c | 8 -
arch/arm/mach-omap2/clock2420_data.c | 2
arch/arm/mach-omap2/clock2430.c | 2
arch/arm/mach-omap2/clock2430_data.c | 2
arch/arm/mach-omap2/clock2xxx.c | 2
arch/arm/mach-omap2/clock33xx_data.c | 2
arch/arm/mach-omap2/clock3xxx.c | 2
arch/arm/mach-omap2/clock3xxx_data.c | 3
arch/arm/mach-omap2/clock44xx_data.c | 3
arch/arm/mach-omap2/cm2xxx_3xxx.c | 3
arch/arm/mach-omap2/common.c | 2
arch/arm/mach-omap2/common.h | 6
arch/arm/mach-omap2/control.c | 2
arch/arm/mach-omap2/control.h | 2
arch/arm/mach-omap2/devices.c | 1
arch/arm/mach-omap2/dpll3xxx.c | 2
arch/arm/mach-omap2/dpll44xx.c | 2
arch/arm/mach-omap2/emu.c | 2
arch/arm/mach-omap2/gpmc-nand.c | 5
arch/arm/mach-omap2/gpmc-onenand.c | 5
arch/arm/mach-omap2/gpmc-smc91x.c | 3
arch/arm/mach-omap2/gpmc.c | 4
arch/arm/mach-omap2/hardware.h | 6
arch/arm/mach-omap2/hsmmc.c | 2
arch/arm/mach-omap2/i2c.c | 1
arch/arm/mach-omap2/id.c | 2
arch/arm/mach-omap2/include/mach/hardware.h | 2
arch/arm/mach-omap2/io.c | 3
arch/arm/mach-omap2/irq.c | 3
arch/arm/mach-omap2/mailbox.c | 3
arch/arm/mach-omap2/mcbsp.c | 5
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 3
arch/arm/mach-omap2/omap-smp.c | 2
arch/arm/mach-omap2/omap-wakeupgen.c | 2
arch/arm/mach-omap2/omap24xx.h | 2
arch/arm/mach-omap2/omap34xx.h | 2
arch/arm/mach-omap2/omap4-common.c | 2
arch/arm/mach-omap2/omap44xx.h | 1
arch/arm/mach-omap2/omap54xx.h | 0
arch/arm/mach-omap2/omap_hwmod.c | 8 -
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 5
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 5
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 3
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1
arch/arm/mach-omap2/omap_l3_noc.c | 3
arch/arm/mach-omap2/omap_phy_internal.c | 3
arch/arm/mach-omap2/opp2420_data.c | 2
arch/arm/mach-omap2/opp2430_data.c | 2
arch/arm/mach-omap2/opp3xxx_data.c | 2
arch/arm/mach-omap2/opp4xxx_data.c | 3
arch/arm/mach-omap2/powerdomain.c | 6
arch/arm/mach-omap2/powerdomains3xxx_data.c | 4
arch/arm/mach-omap2/prm2xxx_3xxx.c | 4
arch/arm/mach-omap2/prm44xx.c | 4
arch/arm/mach-omap2/sdrc2xxx.c | 2
arch/arm/mach-omap2/sleep24xx.S | 3
arch/arm/mach-omap2/sleep34xx.S | 2
arch/arm/mach-omap2/sleep44xx.S | 2
arch/arm/mach-omap2/soc.h | 1
arch/arm/mach-omap2/sram242x.S | 3
arch/arm/mach-omap2/sram243x.S | 3
arch/arm/mach-omap2/sram34xx.S | 3
arch/arm/mach-omap2/ti81xx.h | 0
arch/arm/mach-omap2/timer.c | 3
arch/arm/mach-omap2/twl-common.c | 2
arch/arm/mach-omap2/usb-host.c | 1
arch/arm/mach-omap2/usb-musb.c | 6
arch/arm/mach-omap2/vc.c | 3
arch/arm/mach-omap2/voltagedomains3xxx_data.c | 3
arch/arm/plat-omap/Makefile | 3
arch/arm/plat-omap/counter_32k.c | 2
arch/arm/plat-omap/devices.c | 91 -------
arch/arm/plat-omap/dma.c | 3
arch/arm/plat-omap/include/plat/gpio-switch.h | 54 ----
arch/arm/plat-omap/include/plat/hardware.h | 293 ------------------------
arch/arm/plat-omap/include/plat/omap4-keypad.h | 2
drivers/spi/spi-omap-uwire.c | 3
drivers/watchdog/omap_wdt.c | 5
sound/soc/omap/omap-abe-twl6040.c | 4
sound/soc/omap/omap-mcpdm.c | 2
118 files changed, 475 insertions(+), 687 deletions(-)
rename arch/arm/{plat-omap/include/plat/omap1510.h => mach-omap1/include/mach/omap1510.h} (97%)
rename arch/arm/{plat-omap/include/plat/omap16xx.h => mach-omap1/include/mach/omap16xx.h} (99%)
rename arch/arm/{plat-omap/include/plat/omap7xx.h => mach-omap1/include/mach/omap7xx.h} (98%)
rename arch/arm/{plat-omap/include/plat/am33xx.h => mach-omap2/am33xx.h} (100%)
create mode 100644 arch/arm/mach-omap2/hardware.h
rename arch/arm/{plat-omap/include/plat/omap24xx.h => mach-omap2/omap24xx.h} (98%)
rename arch/arm/{plat-omap/include/plat/omap34xx.h => mach-omap2/omap34xx.h} (98%)
rename arch/arm/{plat-omap/include/plat/omap44xx.h => mach-omap2/omap44xx.h} (98%)
rename arch/arm/{plat-omap/include/plat/omap54xx.h => mach-omap2/omap54xx.h} (100%)
create mode 100644 arch/arm/mach-omap2/soc.h
rename arch/arm/{plat-omap/include/plat/ti81xx.h => mach-omap2/ti81xx.h} (100%)
delete mode 100644 arch/arm/plat-omap/devices.c
delete mode 100644 arch/arm/plat-omap/include/plat/gpio-switch.h
delete mode 100644 arch/arm/plat-omap/include/plat/hardware.h
--
Signature
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 0/4] Series short description
@ 2012-09-01 0:26 ` Tony Lindgren
0 siblings, 0 replies; 32+ messages in thread
From: Tony Lindgren @ 2012-09-01 0:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Here are the changes needed to make hardware.h local for mach-omap2.
These patches are based on v3.6-rc3 and the following patches:
- Arnd's patch "ARM: omap: move platform_data definitions"
- Igor's series "ARM: OMAP: cleanup plat/board.h file"
- Afzal's series "Prepare for GPMC driver conversion (w.r.t MTD)"
- My series "Clean up hardcoded IRQs for mach-omap2, enable SPARSE_IRQ,
plaform_data/gpio-omap.h"
Regards,
Tony
---
Tony Lindgren (4):
ARM: OMAP: Remove unused old gpio-switch.h
ARM: OMAP: Split plat/hardware.h, introduce local hardware.h and soc.h for omap2+
ARM: OMAP2+ Move SoC specific headers to be local to mach-omap2
ARM: OMAP1: Move SoC specific headers from plat to mach for omap1
arch/arm/mach-omap1/board-htcherald.c | 4
arch/arm/mach-omap1/devices.c | 2
arch/arm/mach-omap1/include/mach/hardware.h | 285 +++++++++++++++++++++++
arch/arm/mach-omap1/include/mach/omap1510.h | 3
arch/arm/mach-omap1/include/mach/omap16xx.h | 3
arch/arm/mach-omap1/include/mach/omap7xx.h | 3
arch/arm/mach-omap2/am33xx.h | 0
arch/arm/mach-omap2/board-2430sdp.c | 2
arch/arm/mach-omap2/board-3430sdp.c | 9 -
arch/arm/mach-omap2/board-4430sdp.c | 9 -
arch/arm/mach-omap2/board-am3517crane.c | 1
arch/arm/mach-omap2/board-am3517evm.c | 1
arch/arm/mach-omap2/board-apollon.c | 3
arch/arm/mach-omap2/board-cm-t35.c | 2
arch/arm/mach-omap2/board-cm-t3517.c | 3
arch/arm/mach-omap2/board-devkit8000.c | 22 +-
arch/arm/mach-omap2/board-flash.c | 6
arch/arm/mach-omap2/board-generic.c | 1
arch/arm/mach-omap2/board-h4.c | 3
arch/arm/mach-omap2/board-igep0020.c | 1
arch/arm/mach-omap2/board-ldp.c | 10 -
arch/arm/mach-omap2/board-n8x0.c | 10 -
arch/arm/mach-omap2/board-omap3beagle.c | 12 -
arch/arm/mach-omap2/board-omap3evm.c | 11 -
arch/arm/mach-omap2/board-omap3logic.c | 16 -
arch/arm/mach-omap2/board-omap3pandora.c | 9 -
arch/arm/mach-omap2/board-omap3stalker.c | 20 +-
arch/arm/mach-omap2/board-omap3touchbook.c | 9 -
arch/arm/mach-omap2/board-omap4panda.c | 7 -
arch/arm/mach-omap2/board-overo.c | 14 -
arch/arm/mach-omap2/board-rm680.c | 1
arch/arm/mach-omap2/board-rx51.c | 5
arch/arm/mach-omap2/board-ti8168evm.c | 2
arch/arm/mach-omap2/board-zoom-debugboard.c | 4
arch/arm/mach-omap2/board-zoom-display.c | 4
arch/arm/mach-omap2/board-zoom-peripherals.c | 1
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 2
arch/arm/mach-omap2/clkt_dpll.c | 2
arch/arm/mach-omap2/clock.c | 8 -
arch/arm/mach-omap2/clock2420_data.c | 2
arch/arm/mach-omap2/clock2430.c | 2
arch/arm/mach-omap2/clock2430_data.c | 2
arch/arm/mach-omap2/clock2xxx.c | 2
arch/arm/mach-omap2/clock33xx_data.c | 2
arch/arm/mach-omap2/clock3xxx.c | 2
arch/arm/mach-omap2/clock3xxx_data.c | 3
arch/arm/mach-omap2/clock44xx_data.c | 3
arch/arm/mach-omap2/cm2xxx_3xxx.c | 3
arch/arm/mach-omap2/common.c | 2
arch/arm/mach-omap2/common.h | 6
arch/arm/mach-omap2/control.c | 2
arch/arm/mach-omap2/control.h | 2
arch/arm/mach-omap2/devices.c | 1
arch/arm/mach-omap2/dpll3xxx.c | 2
arch/arm/mach-omap2/dpll44xx.c | 2
arch/arm/mach-omap2/emu.c | 2
arch/arm/mach-omap2/gpmc-nand.c | 5
arch/arm/mach-omap2/gpmc-onenand.c | 5
arch/arm/mach-omap2/gpmc-smc91x.c | 3
arch/arm/mach-omap2/gpmc.c | 4
arch/arm/mach-omap2/hardware.h | 6
arch/arm/mach-omap2/hsmmc.c | 2
arch/arm/mach-omap2/i2c.c | 1
arch/arm/mach-omap2/id.c | 2
arch/arm/mach-omap2/include/mach/hardware.h | 2
arch/arm/mach-omap2/io.c | 3
arch/arm/mach-omap2/irq.c | 3
arch/arm/mach-omap2/mailbox.c | 3
arch/arm/mach-omap2/mcbsp.c | 5
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 3
arch/arm/mach-omap2/omap-smp.c | 2
arch/arm/mach-omap2/omap-wakeupgen.c | 2
arch/arm/mach-omap2/omap24xx.h | 2
arch/arm/mach-omap2/omap34xx.h | 2
arch/arm/mach-omap2/omap4-common.c | 2
arch/arm/mach-omap2/omap44xx.h | 1
arch/arm/mach-omap2/omap54xx.h | 0
arch/arm/mach-omap2/omap_hwmod.c | 8 -
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 5
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 5
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 3
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1
arch/arm/mach-omap2/omap_l3_noc.c | 3
arch/arm/mach-omap2/omap_phy_internal.c | 3
arch/arm/mach-omap2/opp2420_data.c | 2
arch/arm/mach-omap2/opp2430_data.c | 2
arch/arm/mach-omap2/opp3xxx_data.c | 2
arch/arm/mach-omap2/opp4xxx_data.c | 3
arch/arm/mach-omap2/powerdomain.c | 6
arch/arm/mach-omap2/powerdomains3xxx_data.c | 4
arch/arm/mach-omap2/prm2xxx_3xxx.c | 4
arch/arm/mach-omap2/prm44xx.c | 4
arch/arm/mach-omap2/sdrc2xxx.c | 2
arch/arm/mach-omap2/sleep24xx.S | 3
arch/arm/mach-omap2/sleep34xx.S | 2
arch/arm/mach-omap2/sleep44xx.S | 2
arch/arm/mach-omap2/soc.h | 1
arch/arm/mach-omap2/sram242x.S | 3
arch/arm/mach-omap2/sram243x.S | 3
arch/arm/mach-omap2/sram34xx.S | 3
arch/arm/mach-omap2/ti81xx.h | 0
arch/arm/mach-omap2/timer.c | 3
arch/arm/mach-omap2/twl-common.c | 2
arch/arm/mach-omap2/usb-host.c | 1
arch/arm/mach-omap2/usb-musb.c | 6
arch/arm/mach-omap2/vc.c | 3
arch/arm/mach-omap2/voltagedomains3xxx_data.c | 3
arch/arm/plat-omap/Makefile | 3
arch/arm/plat-omap/counter_32k.c | 2
arch/arm/plat-omap/devices.c | 91 -------
arch/arm/plat-omap/dma.c | 3
arch/arm/plat-omap/include/plat/gpio-switch.h | 54 ----
arch/arm/plat-omap/include/plat/hardware.h | 293 ------------------------
arch/arm/plat-omap/include/plat/omap4-keypad.h | 2
drivers/spi/spi-omap-uwire.c | 3
drivers/watchdog/omap_wdt.c | 5
sound/soc/omap/omap-abe-twl6040.c | 4
sound/soc/omap/omap-mcpdm.c | 2
118 files changed, 475 insertions(+), 687 deletions(-)
rename arch/arm/{plat-omap/include/plat/omap1510.h => mach-omap1/include/mach/omap1510.h} (97%)
rename arch/arm/{plat-omap/include/plat/omap16xx.h => mach-omap1/include/mach/omap16xx.h} (99%)
rename arch/arm/{plat-omap/include/plat/omap7xx.h => mach-omap1/include/mach/omap7xx.h} (98%)
rename arch/arm/{plat-omap/include/plat/am33xx.h => mach-omap2/am33xx.h} (100%)
create mode 100644 arch/arm/mach-omap2/hardware.h
rename arch/arm/{plat-omap/include/plat/omap24xx.h => mach-omap2/omap24xx.h} (98%)
rename arch/arm/{plat-omap/include/plat/omap34xx.h => mach-omap2/omap34xx.h} (98%)
rename arch/arm/{plat-omap/include/plat/omap44xx.h => mach-omap2/omap44xx.h} (98%)
rename arch/arm/{plat-omap/include/plat/omap54xx.h => mach-omap2/omap54xx.h} (100%)
create mode 100644 arch/arm/mach-omap2/soc.h
rename arch/arm/{plat-omap/include/plat/ti81xx.h => mach-omap2/ti81xx.h} (100%)
delete mode 100644 arch/arm/plat-omap/devices.c
delete mode 100644 arch/arm/plat-omap/include/plat/gpio-switch.h
delete mode 100644 arch/arm/plat-omap/include/plat/hardware.h
--
Signature
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 0/4] Series short description
@ 2011-08-08 15:37 Bernd Schubert
0 siblings, 0 replies; 32+ messages in thread
From: Bernd Schubert @ 2011-08-08 15:37 UTC (permalink / raw)
To: linux-nfs, linux-ext4; +Cc: hch, yong.fan, linux-fsdevel, tytso, adilger
With the ext3/ext4 directory index implementation hashes are used to specify
offsets for llseek(). For compatibility with NFSv2 and 32-bit user space
on 64-bit systems (kernel space) ext3/ext4 currently only return 32-bit
hashes and therefore the probability of hash collisions for larger directories
is rather high. As recently reported on the NFS mailing list that theoretical
problem also happens on real systems:
http://comments.gmane.org/gmane.linux.nfs/40863
The following series adds two new f_mode flags to tell ext4
to use 32-bit or 64-bit hash values for llseek() calls.
These flags can then used by network file systems, such as NFS, to
request 32-bit or 64-bit offsets (hashes).
Version 2:
- use f_mode instead of O_* flags and also in a separate patch
- introduce EXT4_HTREE_EOF_32BIT and EXT4_HTREE_EOF_64BIT
- fix SEEK_END in ext4_dir_llseek()
- set f_mode flags in NFS code as early as possible and introduce a new
NFSD_MAY_64BIT_COOKIE flag for that
--
Bernd Schubert
Fraunhofer ITWM
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 0/4] Series short description
@ 2010-11-02 22:54 John Bonesio
0 siblings, 0 replies; 32+ messages in thread
From: John Bonesio @ 2010-11-02 22:54 UTC (permalink / raw)
To: glikely-s3s/WqlpOiPyB63q8FvJNQ, david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
The following series implements various changes for merging and modifiying
device trees.
The last one is a first stab at making labels from aliases. This way we can
have a consistent syntax for paths from alias and label references:
&{alias/path/from/alias}
&{label/path/from/label}
There might be a better approach to implementing this. Once of the constraints
I ended up following was to provide line information when there is an attempt
to re-use a label from a deleted or modified node. This constraint (or
requirement) might not be viewed as important like I think. Removing this might
make the changes easier to implemnt but may make it harder for dts writers to
discover the source of errors.
This last patch doesn't include a test case, though I have tested basic
functionality.
---
John Bonesio (4):
Allow nodes to be refrenced by path at the top level.
Implements a new feature for deleting existing device tree nodes.
Implements a new feature for deleting existing properties in device tree nodes.
Allow nodes at the root to be specified by path as well as by label.
Makefile.dtc | 1
checks.c | 20 +++++++
dtc-lexer.l | 38 ++++++++++++-
dtc-parser.y | 86 +++++++++++++++++++++++++++-
dtc.h | 10 +++
flattree.c | 3 +
livetree.c | 118 +++++++++++++++++++++++++++++++++++++--
tests/dtc-checkfails.sh | 2 -
tests/run_tests.sh | 6 ++
tests/test_tree1_merge_path.dts | 41 ++++++++++++++
util.h | 10 +++
11 files changed, 324 insertions(+), 11 deletions(-)
create mode 100644 tests/test_tree1_merge_path.dts
--
Signature
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 0/4] Series short description
@ 2010-10-20 21:44 John Bonesio
0 siblings, 0 replies; 32+ messages in thread
From: John Bonesio @ 2010-10-20 21:44 UTC (permalink / raw)
To: Grant Likely, David Gibson; +Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
The following series implements...
1) new patch to update error messaging
2) new patch to remove existing nodes
3) patch to reference nodes by path or label/path at the root level
I chose the following syntax:
&{/path/to/a/node} [existing syntax, now is allowed at the root level]
&label [existing syntax]
&{label} [new syntax]
&{label/path/to/subnode} [new syntax]
4) patch to undefine properties
- John
---
John Bonesio (4):
Create new and use new print_error that uses printf style formatting.
Implements new features for updating existing device tree nodes.
Allow nodes at the root to be specified by path as well as by label.
Create a new property value that means 'undefined'.
dtc-lexer.l | 34 ++++++++++++++++++++++++--
dtc-parser.y | 47 +++++++++++++++++++++++++++---------
dtc.h | 8 ++++++
flattree.c | 3 ++
livetree.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++-----
srcpos.c | 21 ++++++++++------
srcpos.h | 2 ++
7 files changed, 163 insertions(+), 28 deletions(-)
--
Signature
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 0/4] Series short description
@ 2010-06-17 7:58 Benjamin Zores
0 siblings, 0 replies; 32+ messages in thread
From: Benjamin Zores @ 2010-06-17 7:58 UTC (permalink / raw)
To: linux-arm-kernel
The following series implements support for Marvell 88F6282 SoC.
It should take into account all previously made comments.
---
Benjamin Zores (4):
arch/arm/mach-kirkwood: update MPP definition.
arch/arm/mach-kirkwood: add support for 88F6282-A0 revision
arch/arm/mach-kirkwood: add support for 2nd PCIe port on 88f6282.
arch/arm/mach-kirkwood: add support for 2nd TWSI controller on 88f6282.
arch/arm/mach-kirkwood/addr-map.c | 21 +
arch/arm/mach-kirkwood/common.c | 90 +++
arch/arm/mach-kirkwood/common.h | 10
arch/arm/mach-kirkwood/db88f6281-bp-setup.c | 2
arch/arm/mach-kirkwood/include/mach/bridge-regs.h | 3
arch/arm/mach-kirkwood/include/mach/irqs.h | 4
arch/arm/mach-kirkwood/include/mach/kirkwood.h | 43 +-
arch/arm/mach-kirkwood/mpp.c | 2
arch/arm/mach-kirkwood/mpp.h | 595 +++++++++++----------
arch/arm/mach-kirkwood/mv88f6281gtw_ge-setup.c | 2
arch/arm/mach-kirkwood/netspace_v2-setup.c | 6
arch/arm/mach-kirkwood/netxbig_v2-setup.c | 34 +
arch/arm/mach-kirkwood/openrd-setup.c | 4
arch/arm/mach-kirkwood/pcie.c | 204 +++++--
arch/arm/mach-kirkwood/rd88f6192-nas-setup.c | 2
arch/arm/mach-kirkwood/rd88f6281-setup.c | 2
arch/arm/mach-kirkwood/ts219-setup.c | 8
arch/arm/mach-kirkwood/ts41x-setup.c | 32 +
18 files changed, 663 insertions(+), 401 deletions(-)
--
Signature
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 0/4] Series short description
@ 2009-11-17 14:44 Alan Cox
0 siblings, 0 replies; 32+ messages in thread
From: Alan Cox @ 2009-11-17 14:44 UTC (permalink / raw)
To: linux-kernel, linux-ide
The following series implements...
---
Alan Cox (4):
pata: Update experimental tags
cmd64x: implement serialization as per notes
pata_sis: Implement MWDMA for the UDMA 133 capable chips
pata_via: Blacklist some combinations of Transcend Flash and via
drivers/ata/Kconfig | 8 +--
drivers/ata/pata_cmd64x.c | 132 ++++++++++++++++++++++++++++++++++++++++++---
drivers/ata/pata_sis.c | 88 +++++++++++++++++++++++-------
drivers/ata/pata_via.c | 27 +++++++++
4 files changed, 222 insertions(+), 33 deletions(-)
--
Signature
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/4] Series short description
2009-05-11 17:33 ` Jeff Garzik
@ 2009-05-11 17:58 ` Alan Cox
0 siblings, 0 replies; 32+ messages in thread
From: Alan Cox @ 2009-05-11 17:58 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide
> I was referring to the patch numbering provided by you, in your
> submission, which is the reverse of the order listed above:
>
> patch #1: ICH7 MWDMA timings
> patch #2: TZ90
> patch #3: turn on hotplugging
> patch #4: fix comment
>
> patch #3 is a behavior change IMO very late in -rc cycle, and patch #4
> is not urgent.
Agreed - sorry I'd forgotten that stgit is quite creative with its
ordering.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/4] Series short description
2009-05-11 17:25 ` Alan Cox
@ 2009-05-11 17:33 ` Jeff Garzik
2009-05-11 17:58 ` Alan Cox
0 siblings, 1 reply; 32+ messages in thread
From: Jeff Garzik @ 2009-05-11 17:33 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-ide
Alan Cox wrote:
> On Mon, 11 May 2009 13:21:43 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
>
>> Alan Cox wrote:
>>> A quick batch of PIIX updates
>>> ---
>>>
>>> Alan Cox (4):
>>> ata_piix: Remove stale comment
>>> ata_piix: Turn on hotplugging support for older chips
>>> ata_piix: The Sony TZ90 needs the cable type hardcoding
>>> ata_piix: ICH7 does not support correct MWDMA timings
>> I guess 1 & 2 are #upstream-fixes material, and 3 & 4 are #upstream ?
>
> I'd say they are all fixes. In terms of urgency #4 hasn't been reported
> by anyone it was found when checking errata, #3 is a real problem
> encountered by users #2 affects only fairly obscure hardware and isn't a
> regression, #1 is a comment.
I was referring to the patch numbering provided by you, in your
submission, which is the reverse of the order listed above:
patch #1: ICH7 MWDMA timings
patch #2: TZ90
patch #3: turn on hotplugging
patch #4: fix comment
patch #3 is a behavior change IMO very late in -rc cycle, and patch #4
is not urgent.
Jeff
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/4] Series short description
2009-05-11 17:21 ` Jeff Garzik
@ 2009-05-11 17:25 ` Alan Cox
2009-05-11 17:33 ` Jeff Garzik
0 siblings, 1 reply; 32+ messages in thread
From: Alan Cox @ 2009-05-11 17:25 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide
On Mon, 11 May 2009 13:21:43 -0400
Jeff Garzik <jeff@garzik.org> wrote:
> Alan Cox wrote:
> > A quick batch of PIIX updates
> > ---
> >
> > Alan Cox (4):
> > ata_piix: Remove stale comment
> > ata_piix: Turn on hotplugging support for older chips
> > ata_piix: The Sony TZ90 needs the cable type hardcoding
> > ata_piix: ICH7 does not support correct MWDMA timings
>
> I guess 1 & 2 are #upstream-fixes material, and 3 & 4 are #upstream ?
I'd say they are all fixes. In terms of urgency #4 hasn't been reported
by anyone it was found when checking errata, #3 is a real problem
encountered by users #2 affects only fairly obscure hardware and isn't a
regression, #1 is a comment.
I've also now confirmed with the Intel hardware folks that there isn't
any reason we can't turn on parallel probing in ata_piix.
Alan
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/4] Series short description
2009-05-06 16:08 Alan Cox
@ 2009-05-11 17:21 ` Jeff Garzik
2009-05-11 17:25 ` Alan Cox
0 siblings, 1 reply; 32+ messages in thread
From: Jeff Garzik @ 2009-05-11 17:21 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-ide
Alan Cox wrote:
> A quick batch of PIIX updates
> ---
>
> Alan Cox (4):
> ata_piix: Remove stale comment
> ata_piix: Turn on hotplugging support for older chips
> ata_piix: The Sony TZ90 needs the cable type hardcoding
> ata_piix: ICH7 does not support correct MWDMA timings
I guess 1 & 2 are #upstream-fixes material, and 3 & 4 are #upstream ?
Jeff
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 0/4] Series short description
@ 2009-05-06 16:08 Alan Cox
2009-05-11 17:21 ` Jeff Garzik
0 siblings, 1 reply; 32+ messages in thread
From: Alan Cox @ 2009-05-06 16:08 UTC (permalink / raw)
To: linux-ide, jeff
A quick batch of PIIX updates
---
Alan Cox (4):
ata_piix: Remove stale comment
ata_piix: Turn on hotplugging support for older chips
ata_piix: The Sony TZ90 needs the cable type hardcoding
ata_piix: ICH7 does not support correct MWDMA timings
drivers/ata/ata_piix.c | 28 +++++++++++++++++++---------
1 files changed, 19 insertions(+), 9 deletions(-)
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 0/4] Series short description
@ 2008-10-20 22:25 ` Eric Paris
0 siblings, 0 replies; 32+ messages in thread
From: Eric Paris @ 2008-10-20 22:25 UTC (permalink / raw)
To: linux-kernel, linux-audit; +Cc: viro, sgrubb, serue, morgan
The following series implements...
---
Eric Paris (4):
AUDIT: emit new record type showing all capset information
AUDIT: audit when fcaps increase the permitted or inheritable capabilities
AUDIT: output permitted and inheritable fcaps in PATH records
CAPABILITIES: add cpu endian vfs caps structure
include/linux/audit.h | 22 +++++
include/linux/capability.h | 12 +++
kernel/auditsc.c | 201 +++++++++++++++++++++++++++++++++++++++++++-
kernel/capability.c | 3 +
security/commoncap.c | 131 ++++++++++++++++-------------
5 files changed, 308 insertions(+), 61 deletions(-)
--
Signature
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 0/4] Series short description
@ 2008-10-20 22:25 ` Eric Paris
0 siblings, 0 replies; 32+ messages in thread
From: Eric Paris @ 2008-10-20 22:25 UTC (permalink / raw)
To: linux-kernel, linux-audit; +Cc: viro, morgan
The following series implements...
---
Eric Paris (4):
AUDIT: emit new record type showing all capset information
AUDIT: audit when fcaps increase the permitted or inheritable capabilities
AUDIT: output permitted and inheritable fcaps in PATH records
CAPABILITIES: add cpu endian vfs caps structure
include/linux/audit.h | 22 +++++
include/linux/capability.h | 12 +++
kernel/auditsc.c | 201 +++++++++++++++++++++++++++++++++++++++++++-
kernel/capability.c | 3 +
security/commoncap.c | 131 ++++++++++++++++-------------
5 files changed, 308 insertions(+), 61 deletions(-)
--
Signature
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 0/4] Series short description
@ 2007-07-19 18:34 grant.likely
0 siblings, 0 replies; 32+ messages in thread
From: grant.likely @ 2007-07-19 18:34 UTC (permalink / raw)
To: linuxppc-dev
The following series makes the mpc8349emitx* cuImage work 'out of the box'
Major changes are adding the linux,network-index property to the Ethernet
nodes and adding a default linux,stdout-path to the .dts files. With
these changes, a cuImage created by 'make mpc834x_itx_defconfig; make zImage'
should boot without changes.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/4] Series short description
2006-11-23 23:16 Yann Dirson
@ 2006-11-24 15:37 ` Catalin Marinas
0 siblings, 0 replies; 32+ messages in thread
From: Catalin Marinas @ 2006-11-24 15:37 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
On 23/11/06, Yann Dirson <ydirson@altern.org> wrote:
> The following adds a --patch flag to "stg refresh". I mainly needed it to
> edit the log message in patches down the stack, but with some work it could
> be used to record changes in another file and come back.
>
> That would require to pop patches with --keep,
pop_patches(keep=True) allows this (I already added it to your patch).
This option actually applies the reverse of the patch between the
current index and the bottom of the last patch to be popped. If it
fails, it doesn't affect the current tree and reports an error.
> and if we ask to only record
> a subset of the changes, we would need to implement "push --keep" first.
The "push --keep" is a bit more complicated to implement since it
would usually have to generate commits (pop doesn't need to) since
usually the base of the pushed patches might have changed (especially
with the refresh --patch). It is even more complicated if the changes
you want to preserve affect a file modified by the pushed patches.
A solution I see is to generate a temporary diff, push the patches you
want and fold this temporary diff (the diff can be temporarily written
to a local file so that you don't lose them in case of an error or
Ctrl-C). If the push fails (conflicts) or the diff no longer applies,
just undo the push and re-apply the diff. There is no way to simply
check whether all the patches apply (git-apply --check) since you
can't generate a single diff for all the pushed patches (which might
not be in the committed order).
--
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 0/4] Series short description
@ 2006-11-23 23:16 Yann Dirson
2006-11-24 15:37 ` Catalin Marinas
0 siblings, 1 reply; 32+ messages in thread
From: Yann Dirson @ 2006-11-23 23:16 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
The following adds a --patch flag to "stg refresh". I mainly needed it to
edit the log message in patches down the stack, but with some work it could
be used to record changes in another file and come back.
That would require to pop patches with --keep, and if we ask to only record
a subset of the changes, we would need to implement "push --keep" first.
This patch is not perfect, since it reverses a list twice, but I did not
find an elegant way to make it better. Python gurus, feel free to improve
this :)
While I was at it, I noticed that "stg goto" need not revert the applied list
if we're going to an unapplied patch (sorta compensate my extraneous revert above ;),
and I noticed a DWIM behaviour on the (should-be)-erroneous "refresh --ack --sign".
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2012-09-01 0:26 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-22 0:31 [PATCH 0/4] Series short description Alexey Zaytsev
2010-11-22 0:33 ` [PATCH 1/4] fanotify: Shrink struct fanotify_event_metadata by 32 bits Alexey Zaytsev
2010-11-26 7:01 ` Alexey Zaytsev
2010-11-26 7:01 ` Alexey Zaytsev
2010-11-22 0:33 ` [PATCH 2/4] VFS: Tell fsnotify what part of the file might have changed Alexey Zaytsev
2010-11-22 0:33 ` [PATCH 3/4] fsnotify: Handle the file change ranges Alexey Zaytsev
2010-11-22 0:37 ` [PATCH 4/4] fanotify: Expose the file changes to the user Alexey Zaytsev
2010-11-26 10:11 ` Tvrtko Ursulin
2010-11-26 11:21 ` Alexey Zaytsev
2010-11-26 11:41 ` Tvrtko Ursulin
2010-11-26 12:11 ` Alexey Zaytsev
2010-11-29 16:14 ` Eric Paris
2010-11-29 16:51 ` Alexey Zaytsev
2010-11-29 18:14 ` Eric Paris
2010-11-29 17:11 ` Tvrtko Ursulin
-- strict thread matches above, loose matches on Subject: below --
2012-09-01 0:26 [PATCH 0/4] Series short description Tony Lindgren
2012-09-01 0:26 ` Tony Lindgren
2011-08-08 15:37 Bernd Schubert
2010-11-02 22:54 John Bonesio
2010-10-20 21:44 John Bonesio
2010-06-17 7:58 Benjamin Zores
2009-11-17 14:44 Alan Cox
2009-05-06 16:08 Alan Cox
2009-05-11 17:21 ` Jeff Garzik
2009-05-11 17:25 ` Alan Cox
2009-05-11 17:33 ` Jeff Garzik
2009-05-11 17:58 ` Alan Cox
2008-10-20 22:25 Eric Paris
2008-10-20 22:25 ` Eric Paris
2007-07-19 18:34 grant.likely
2006-11-23 23:16 Yann Dirson
2006-11-24 15:37 ` Catalin Marinas
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.