* RE: acpi_thread_id = acpi_os_get_thread_id()
From: Moore, Robert @ 2006-04-03 14:35 UTC (permalink / raw)
To: Brown, Len; +Cc: linux-acpi
HP-UX wanted the new type. It can be defined as necessary for Linux;
However,I can change the default to UINT32 if that's what is used on
most operating systems.
The information as to thread ID can be very useful when debugging multi
threaded issues, and will probably become more important as we encounter
more of these. I would like to keep it around for the time being.
Bob
> -----Original Message-----
> From: Brown, Len
> Sent: Saturday, April 01, 2006 12:14 AM
> To: Moore, Robert
> Cc: linux-acpi@vger.kernel.org
> Subject: acpi_thread_id = acpi_os_get_thread_id()
>
> Bob,
> with the new type acpi_thread_id, it seems that the thread_id grows
from
> 32-bits
> to 64-bits on a 64-bit mahcine.
>
> acpi_os_get_thread_id() currently returns task.pid on Linux,
> a 32-bit integer on both 32 and 64-bit machines.
>
> So if acpi_os_get_thread_id() is called at interrupt level,
> its return value is meaningless.
>
> Linux doesn't define ACPI_MUTEX_DEBUG, and looks like it never will.
>
> Is it possible to delete the concept of acpi_os_get_thread_id()?
> I'm wondering at the moment if the right thing isn't to do this:
>
> #define acpi_os_get_thread_id() (0)
>
> thanks,
> -Len
^ permalink raw reply
* Re: 2.6.16 not booting due to ACPI revision 20060127
From: xb @ 2006-04-03 14:34 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <44310983.3070000@bull.net>
[-- Attachment #1: Type: text/plain, Size: 3843 bytes --]
xb wrote:
> Hi all,
>
> We have platforms that do not boot in 2.6.16, but boot OK with 2.6.15
> (loop in ACPI code).
> After some investigations, I found this is due to pci buses that are
> described in the configuration, but not available in limited
> configurations.
> These buses have a _STA method, but no _INI method.
> With 2.6.15, the _STA method is run, and as the bus is not present,
> the bus and all devices behind it are ignored.
> With 2.6.16, as no _INI method is provided for the bus, _STA method is
> not run, and then we loop when executing methods for devices behind
> the not present bus.
>
> Having a look to ACPI specification, I could find nowhere the
> restriction that _STA method is called only when an _INI method is
> provided for the device:
>
> "6.5.1 _INI (Init)
> ...
> If the _STA method indicates that the device is present, OSPM will
> evaluate the _INI for the device (if the _INI method exists) and will
> examine each of the children of the device for _INI methods. If the
> _STA method indicates that the device is not present, OSPM will not
> run the _INI and will not examine the children of the device for _INI
> methods. "
>
>
> traces -----------------------------------------------
>
>
> Device PC11
> 000060e4: 02 . . Name _HID
> 000060e9: 03 . . . PNP0A03 PCI Bus 0x030ad041
> 000060ee: 02 . . Name _UID
> 000060f3: 03 . . . 0x0b
> 000060f5: 02 . . Name _ADR
> 000060fa: 03 . . . 0x00
> 000060fc: 02 ---- 'PCI bus number setup by the BIOS' Method _BBN
> 00006102: 03 . . . 0x00
> 00006103: 03 . . . Return
> 00006104: 04 . . . . path: \_SB_.CSFF.IO15.B1__
> 00006117: 02 ---- 'Dynamic_Statu' Method _STA
> 0000611d: 03 . . . 0x00
> 0000611e: 03 . . . If
> 00006120: 04 . . . . LEqual
> 00006121: 05 . . . . . path: \_SB_.CSFF.IO11.HUBD
> 00006134: 05 . . . . . 0x00
> 00006136: 04 . . . . Return
> 00006137: 05 . . . . . 0x0f
> 00006139: 03 . . . Return
> 0000613a: 04 . . . . 0x00
> 0000613c: 02 ---- 'Current Resource Setting' Method _CRS
> 00006142: 03 . . . 0x00
> 00006143: 03 . . . Return
> 00006144: 04 . . . . path: \_SB_.HLRS
> 0000614e: 03 . . . 0x01
> 00006150: 03 . . . 0x01
> 00006152: 02
>
I checked that the following patch fixes the problem:
--- linux-2.6.16-old/drivers/acpi/namespace/nsinit.c 2006-03-31
18:26:23.000000000 +0200
+++ linux-2.6.16-new/drivers/acpi/namespace/nsinit.c 2006-04-03
14:57:28.000000000 +0200
@@ -362,19 +362,6 @@ acpi_ns_init_one_device(acpi_handle obj_
info->device_count++;
/*
- * Check if the _INI method exists for this device -
- * if _INI does not exist, there is no need to run _STA
- * No _INI means device requires no initialization
- */
- status = acpi_ns_search_node(*ACPI_CAST_PTR(u32, METHOD_NAME__INI),
- device_node, ACPI_TYPE_METHOD, &ini_node);
- if (ACPI_FAILURE(status)) {
- /* No _INI method found - move on to next device */
-
- return_ACPI_STATUS(AE_OK);
- }
-
- /*
* Run _STA to determine if we can run _INI on the device -
* the device must be present before _INI can be run.
* However, _STA is not required - assume device present if no _STA
@@ -405,6 +392,17 @@ acpi_ns_init_one_device(acpi_handle obj_
}
/*
+ * Check if the _INI method exists for this device -
+ * No _INI means device requires no initialization
+ */
+ status = acpi_ns_search_node(*ACPI_CAST_PTR(u32, METHOD_NAME__INI),
+ device_node, ACPI_TYPE_METHOD, &ini_node);
+ if (ACPI_FAILURE(status)) {
+ /* No _INI method found - move on to next device */
+ return_ACPI_STATUS(AE_OK);
+ }
+
+ /*
* The device is present and _INI exists. Run the _INI method.
* (We already have the _INI node from above)
*/
[-- Attachment #2: xavier.bru.vcf --]
[-- Type: text/x-vcard, Size: 304 bytes --]
begin:vcard
fn:Xavier Bru
n:Bru;Xavier
adr:;;1 rue de Provence, BP 208;38432 Echirolles Cedex;;;France
email;internet:Xavier.Bru@bull.net
title:BULL/DT/Open Software/linux/ia64
tel;work:+33 (0)4 76 29 77 45
tel;fax:+33 (0)4 76 29 77 70
x-mozilla-html:TRUE
url:http://www.bull.com
version:2.1
end:vcard
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Linus Torvalds @ 2006-04-03 14:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kees-Jan Dijkzeul, git
In-Reply-To: <Pine.LNX.4.63.0604031521170.4011@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 3 Apr 2006, Johannes Schindelin wrote:
>
> The problem is not mmap() on cygwin, but that a fork() has to jump through
> loops to reinstall the open file descriptors on cygwin. If the
> corresponding file was deleted, that fails. Therefore, we work around that
> on cygwin by actually reading the file into memory, *not* mmap()ing it.
Well, we could actually do a _real_ mmap on pack-files. The pack-files are
much better mmap'ed - there we don't _want_ them to be removed while we're
using them. It was the index file etc that was problematic.
Maybe the cygwin fake mmap should be triggered only for the index (and
possibly the individual objects - if only because there doing a
malloc+read may actually be faster).
Using malloc+read on pack-files is pretty wasteful, since we usually only
use a very small part of them (ie if we have a 1.5GB pack-file, it's sad
to read all of it, when we'd usually actually access just a small small
fraction of it).
That said, I think git _does_ have problems with large pack-files. We have
some 32-bit issues etc, and just virtual address space things. So for now,
it's probably best to limit pack-files to the few-hundred-meg size, and
create serveral smaller ones rather than one huge one.
Linus
^ permalink raw reply
* RE: Zen and Pacifica
From: Petersson, Mats @ 2006-04-03 14:33 UTC (permalink / raw)
To: Dave Feustel, xen-devel; +Cc: Mark Williamson
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of
> Dave Feustel
> Sent: 31 March 2006 17:52
> To: xen-devel@lists.xensource.com
> Cc: Mark Williamson
> Subject: Re: [Xen-devel] Zen and Pacifica
>
> On Friday 31 March 2006 10:41, Mark Williamson wrote:
> > > I expect to buy an AMD64 Pacifica-enabled computer in the
> 2nd half
> > > of this year to use with OpenBSD in 64-bit mode. I would
> like to use
> > > Xen, but as far as I have been able to determine, Xen
> 3.0 does not
> > > support AMD Pacifica.
> > > Am I wrong about that?
> >
> > It'll be supported in the 3.0.2 release - it's in the
> -unstable tree
> > right now.
>
> Will 3.0.2 support running unmodified operating systems?
> That's the feature I need to run OpenBSD under Xen.
Yes, absolutely. However, I must "warn" you that OpenBSD is not on our
"target-list", so it's possible (although somewhat unlikely) that it
will not work right - every OS has it's own quirks during specific small
sections of code (switch from real to protected mode [particularly code
that "abuses" this switch, like "Big Real-Mode" can cause problems, as
the internal state of the processor and the "apparent state" aren't the
same[1]], page table updates, special IO operations, etc) that may need
some special attention in the hypervisor.
I'm not at all saying "Don't do this", but rather setting your
expectations that it's a small possibility that something is broken.
It's probably not very hard to fix if it is, it just takes someones time
to figure out why it's broken, and how to fix it - usually, it's just a
simple case of another "if (x) do_something_special();" in some
function. And I'd say there's 98% chance that it works just fine as is.
2% risk that there's a problem...
Also, there's a few months yet until the second half of this year, so we
may well have fixed all the remaining bugs 'til then... ;-)
[1] If anyone wants more details on how this works, please fire me a
personal mail... ;-)
--
Mats
>
> When is 3.0.2 likely to be released?
>
> Thanks,
> Dave
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
^ permalink raw reply
* Re: [patch 1/1] sys_sync_file_range()
From: Jens Axboe @ 2006-04-03 14:31 UTC (permalink / raw)
To: Andrew Morton
Cc: neilb, nathans, linux-kernel, drepper, mtk-manpages, nickpiggin
In-Reply-To: <20060403012753.218db397.akpm@osdl.org>
On Mon, Apr 03 2006, Andrew Morton wrote:
> Jens Axboe <axboe@suse.de> wrote:
> >
> > On Mon, Apr 03 2006, Neil Brown wrote:
> > > On Friday March 31, nathans@sgi.com wrote:
> > > > On Thu, Mar 30, 2006 at 06:58:46PM +1100, Neil Brown wrote:
> > > > > On Wednesday March 29, akpm@osdl.org wrote:
> > > > > > Remove the recently-added LINUX_FADV_ASYNC_WRITE and LINUX_FADV_WRITE_WAIT
> > > > > > fadvise() additions, do it in a new sys_sync_file_range() syscall
> > > > > > instead.
> > > > >
> > > > > Hmmm... any chance this could be split into a sys_sync_file_range and
> > > > > a vfs_sync_file_range which takes a 'struct file*' and does less (or
> > > > > no) sanity checking, so I can call it from nfsd?
> > > > >
> > > > > Currently I implement COMMIT (which has a range) with a by messing
> > > > > around with filemap_fdatawrite and filemap_fdatawait (ignoring the
> > > > > range) and I'd rather than a vfs helper.
> > > >
> > > > I'm not 100% sure, but it looks like the PF_SYNCWRITE process flag
> > > > should be set on the nfsd's while they're doing that, which doesn't
> > > > seem to be happening atm. Looks like a couple of the IO schedulers
> > > > will make use of that knowledge now. All the more reason for a VFS
> > > > helper here I guess. ;)
> > >
> > > PF_SYNCWRITE? What's that???
> > >
> > > (find | xargs grep ...)
> > > Oh. The block device schedulers like to know if a request is sync or
> > > async (and all reads are assumed to be sync) - which is reasonable -
> > > and so have a per-task flag to tell them - which isn't (IMO).
> > >
> > > md/raid (particularly raid5) often does the write from a different
> > > process than generated the original request, so that will break
> > > completely.
> >
> > I don't think any disagrees with you, the sync-write process flag is
> > indeed an atrocious beast...
>
> Yeah. PF_SYNCWRITE was a performance tweak for the anticipatory scheduler.
> As cfq is using it as well now (hopefully to good effect) I guess it could
> be formalised more.
Yup, both 'as' and 'cfq' would prefer to just look at a SYNC bio flag
instead. But the logic itself is definitely needed.
> > > What is wrong with a bio flag I wonder....
> >
> > Nothing, in fact I would love for it to be changed. I'm sure such a
> > patch would be accepted with open arms! :-)
>
> I think once someone starts coding it, they'll become a big fan of
> PF_SYNCWRITE...
They might not become a big fan, but they'll surely appreciate the
simplicity of it :-)
> For the page writeback functions it's probably possible to use
> writeback_control.sync_mode=WB_SYNC_ALL as a trigger, propagate that into
> the IO layer. Maybe that'll always be sufficient - it's hard to tell. The
> writeback paths are twisty and deep...
>
> Then again, using WB_SYNC_ALL as a hint that this process will be waiting
> for this writeout to complete is a bit hacky too - it doesn't _really_ mean
> that - it just means that I/O should be _started_ against all relevant
> dirty data.
>
> Good luck ;)
It's not a hard problem, but it will definitely cost a little sweat to
go through. I'm sure Neil could pull it off, the question is more if he
wants to :-)
--
Jens Axboe
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Linus Torvalds @ 2006-04-03 14:29 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git Mailing List
In-Reply-To: <4430D352.4010707@vilain.net>
On Mon, 3 Apr 2006, Sam Vilain wrote:
>
> "Patch dependency chains", the best plain-English term we could find for
> the scary sounding darcs term "patch calculus", are said by some to be a
> very good reason to use a system like darcs, even to some its
> fundamental advantage over systems such as git.
I really think that darcs is just "nice theory", and has nothing to do
with real life.
Terms like "patch calculus" may sound cool and useful, but let's face it,
the proof is in the pudding, and quite frankly, I would bet that trying to
do something like that on a real project would just be a total disaster.
I want my merges simple. I want them to take a couple of seconds. I don't
want to see strange patch dependencies that nobody cares about. And I very
much don't want to see theory over practice.
Linus
^ permalink raw reply
* [2.6.16 PATCH] Filesystem Events Reporter v1
From: Yi Yang @ 2006-04-03 14:28 UTC (permalink / raw)
To: LKML; +Cc: Andrew Morton, Evgeniy Polyakov, Matt Helsley
This patch has some very big changes with comparison to Filesystem Events Connector v4,
the following features are added newly:
- Use netlink instead of connector.
- Every application using fsevent can set its own fsevent filter list
without effect in other applications using fsevent, there are three
filter lists, they are pid filter list, uid filetr list and gid
filter list, respectively, moreover, there is a fsevent mask used to
control those fsevents which fail to match three filter lists, an
application using fsevent can listen those fsevents it want to
monitor and ignore those fsevents it doesn't interest in by set
series of filters, there is a fsevent mask used to take effects on
all the applications using fsevent, it can be set by sysctl and proc
interface(not implemented).
- Remove lock race overhead and file system code path delay completely
by a per cpu fsevent queue and kthread per cpu, fsevent_send just
mallocs a skb and insert the percpu queue and wake up fseventd
kthread, then return immediately, fseventd per cpu is responsible for
send fsevent to userspace application.
fs/Kconfig | 10
fs/Makefile | 1
fs/fsevent.c | 642 ++++++++++++++++++++++++++++++++++++++++++++++
fs/namespace.c | 12
include/linux/fsevent.h | 132 +++++++++
include/linux/fsnotify.h | 37 ++
include/linux/netlink.h | 3
7 files changed, 836 insertions(+), 1 deletion(-)
Signed-off-by: Yi Yang <yang.y.yi@gmail.com>
--- a/include/linux/netlink.h.orig 2006-03-31 22:58:50.000000000 +0800
+++ b/include/linux/netlink.h 2006-03-31 23:00:22.000000000 +0800
@@ -20,7 +20,8 @@
#define NETLINK_IP6_FW 13
#define NETLINK_DNRTMSG 14 /* DECnet routing messages */
#define NETLINK_KOBJECT_UEVENT 15 /* Kernel messages to userspace */
-#define NETLINK_GENERIC 16
+#define NETLINK_FSEVENT 16 /* File system events to userspace */
+#define NETLINK_GENERIC 17
#define MAX_LINKS 32
--- a/include/linux/fsnotify.h.orig 2006-01-03 11:21:10.000000000 +0800
+++ b/include/linux/fsnotify.h 2006-03-27 23:09:18.000000000 +0800
@@ -15,6 +15,7 @@
#include <linux/dnotify.h>
#include <linux/inotify.h>
+#include <linux/fsevent.h>
/*
* fsnotify_move - file old_name at old_dir was moved to new_name at new_dir
@@ -45,6 +46,8 @@ static inline void fsnotify_move(struct
if (source) {
inotify_inode_queue_event(source, IN_MOVE_SELF, 0, NULL);
}
+ raise_fsevent_move(old_dir, old_name, new_dir, new_name,
+ FSEVENT_MOVE | (isdir?FSEVENT_ISDIR:0));
}
/*
@@ -56,6 +59,8 @@ static inline void fsnotify_nameremove(s
isdir = IN_ISDIR;
dnotify_parent(dentry, DN_DELETE);
inotify_dentry_parent_queue_event(dentry, IN_DELETE|isdir, 0, dentry->d_name.name);
+ raise_fsevent(dentry,
+ FSEVENT_DELETE | (isdir?FSEVENT_ISDIR:0));
}
/*
@@ -74,6 +79,7 @@ static inline void fsnotify_create(struc
{
inode_dir_notify(inode, DN_CREATE);
inotify_inode_queue_event(inode, IN_CREATE, 0, name);
+ raise_fsevent_create(inode, name, FSEVENT_CREATE);
}
/*
@@ -83,6 +89,8 @@ static inline void fsnotify_mkdir(struct
{
inode_dir_notify(inode, DN_CREATE);
inotify_inode_queue_event(inode, IN_CREATE | IN_ISDIR, 0, name);
+ raise_fsevent_create(inode, name,
+ FSEVENT_CREATE | FSEVENT_ISDIR);
}
/*
@@ -99,6 +107,8 @@ static inline void fsnotify_access(struc
dnotify_parent(dentry, DN_ACCESS);
inotify_dentry_parent_queue_event(dentry, mask, 0, dentry->d_name.name);
inotify_inode_queue_event(inode, mask, 0, NULL);
+ raise_fsevent(dentry, FSEVENT_ACCESS |
+ ((S_ISDIR(inode->i_mode))?FSEVENT_ISDIR:0));
}
/*
@@ -115,6 +125,8 @@ static inline void fsnotify_modify(struc
dnotify_parent(dentry, DN_MODIFY);
inotify_dentry_parent_queue_event(dentry, mask, 0, dentry->d_name.name);
inotify_inode_queue_event(inode, mask, 0, NULL);
+ raise_fsevent(dentry, FSEVENT_MODIFY |
+ ((S_ISDIR(inode->i_mode))?FSEVENT_ISDIR:0));
}
/*
@@ -130,6 +142,9 @@ static inline void fsnotify_open(struct
inotify_dentry_parent_queue_event(dentry, mask, 0, dentry->d_name.name);
inotify_inode_queue_event(inode, mask, 0, NULL);
+ raise_fsevent(dentry, FSEVENT_OPEN |
+ ((S_ISDIR(inode->i_mode))?FSEVENT_ISDIR:0));
+
}
/*
@@ -148,6 +163,8 @@ static inline void fsnotify_close(struct
inotify_dentry_parent_queue_event(dentry, mask, 0, name);
inotify_inode_queue_event(inode, mask, 0, NULL);
+ raise_fsevent(dentry, FSEVENT_CLOSE |
+ ((S_ISDIR(inode->i_mode))?FSEVENT_ISDIR:0));
}
/*
@@ -163,6 +180,8 @@ static inline void fsnotify_xattr(struct
inotify_dentry_parent_queue_event(dentry, mask, 0, dentry->d_name.name);
inotify_inode_queue_event(inode, mask, 0, NULL);
+ raise_fsevent(dentry, FSEVENT_MODIFY_ATTRIB |
+ ((S_ISDIR(inode->i_mode))?FSEVENT_ISDIR:0));
}
/*
@@ -213,6 +232,24 @@ static inline void fsnotify_change(struc
inotify_dentry_parent_queue_event(dentry, in_mask, 0,
dentry->d_name.name);
}
+
+#ifdef CONFIG_FS_EVENTS
+ {
+ u32 fsevent_mask = 0;
+ if (ia_valid & (ATTR_UID | ATTR_GID | ATTR_MODE))
+ fsevent_mask |= FSEVENT_MODIFY_ATTRIB;
+ if ((ia_valid & ATTR_ATIME) && (ia_valid & ATTR_MTIME))
+ fsevent_mask |= FSEVENT_MODIFY_ATTRIB;
+ else if (ia_valid & ATTR_ATIME)
+ fsevent_mask |= FSEVENT_ACCESS;
+ else if (ia_valid & ATTR_MTIME)
+ fsevent_mask |= FSEVENT_MODIFY;
+ if (ia_valid & ATTR_SIZE)
+ fsevent_mask |= FSEVENT_MODIFY;
+ if (fsevent_mask)
+ raise_fsevent(dentry, fsevent_mask);
+ }
+#endif /* CONFIG_FS_EVENTS */
}
#ifdef CONFIG_INOTIFY /* inotify helpers */
--- a/fs/namespace.c.orig 2006-03-25 23:13:42.000000000 +0800
+++ b/fs/namespace.c 2006-03-27 23:09:18.000000000 +0800
@@ -25,6 +25,7 @@
#include <linux/mount.h>
#include <asm/uaccess.h>
#include <asm/unistd.h>
+#include <linux/fsevent.h>
#include "pnode.h"
extern int __init init_rootfs(void);
@@ -612,6 +613,13 @@ asmlinkage long sys_umount(char __user *
goto dput_and_out;
retval = do_umount(nd.mnt, flags);
+
+ if (retval == 0) {
+ char * tmp = getname(name);
+ raise_fsevent_umount(tmp);
+ putname(tmp);
+ }
+
dput_and_out:
path_release_on_umount(&nd);
out:
@@ -1459,6 +1467,10 @@ asmlinkage long sys_mount(char __user *
retval = do_mount((char *)dev_page, dir_page, (char *)type_page,
flags, (void *)data_page);
unlock_kernel();
+
+ if (retval == 0)
+ raise_fsevent_mount((char *)dev_page, dir_page);
+
free_page(data_page);
out3:
--- a/fs/Kconfig.orig 2006-03-31 21:23:20.000000000 +0800
+++ b/fs/Kconfig 2006-04-03 22:01:17.000000000 +0800
@@ -405,6 +405,16 @@ config INOTIFY
If unsure, say Y.
+config FS_EVENTS
+ tristate "Report filesystem events to userspace"
+ ---help---
+ Provide a facility that reports filesystem events to userspace. The
+ reported event include access, write, utime, chmod, chown, chgrp,
+ close, open, create, rename, unlink, mkdir, rmdir, mount, umount.
+
+ The user can set filesystem events filter to filter its events, so
+ that he just get those events he concerns.
+
config QUOTA
bool "Quota support"
help
--- a/fs/Makefile.orig 2006-03-31 21:23:33.000000000 +0800
+++ b/fs/Makefile 2006-03-31 21:30:58.000000000 +0800
@@ -13,6 +13,7 @@ obj-y := open.o read_write.o file_table.
ioprio.o pnode.o drop_caches.o
obj-$(CONFIG_INOTIFY) += inotify.o
+obj-$(CONFIG_FS_EVENTS) += fsevent.o
obj-$(CONFIG_EPOLL) += eventpoll.o
obj-$(CONFIG_COMPAT) += compat.o compat_ioctl.o
--- /dev/null 2003-01-30 18:24:37.000000000 +0800
+++ b/include/linux/fsevent.h 2006-04-02 01:35:04.000000000 +0800
@@ -0,0 +1,132 @@
+/*
+ * fsevent.h - filesystem events connector
+ *
+ * Copyright (C) 2006 Yi Yang <yang.y.yi@gmail.com>
+ * Based on cn_proc.h by Matt Helsley, IBM Corp
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef LINUX_FSEVENT_H
+#define LINUX_FSEVENT_H
+
+#include <linux/types.h>
+#include <linux/time.h>
+#include <linux/netlink.h>
+
+enum fsevent_type {
+ FSEVENT_ACCESS = 0x00000001, /* File was accessed */
+ FSEVENT_MODIFY = 0x00000002, /* File was modified */
+ FSEVENT_MODIFY_ATTRIB = 0x00000004, /* Metadata changed */
+ FSEVENT_CLOSE = 0x00000008, /* File was closed */
+ FSEVENT_OPEN = 0x00000010, /* File was opened */
+ FSEVENT_MOVE = 0x00000020, /* File was moved */
+ FSEVENT_CREATE = 0x00000040, /* File was created */
+ FSEVENT_DELETE = 0x00000080, /* File was deleted */
+ FSEVENT_MOUNT = 0x00000100, /* File system is mounted */
+ FSEVENT_UMOUNT = 0x00000200, /* File system is umounted */
+
+ /* The following definitions are commands for event filter
+ * , in acknowlege event for the corresponding command, it
+ * will set to type field of struct fsevent.
+ */
+ FSEVENT_FILTER_ALL = 0x08000000, /* For all events */
+ FSEVENT_FILTER_PID = 0x10000000, /* For some process ID */
+ FSEVENT_FILTER_UID = 0x20000000, /* For some user ID */
+ FSEVENT_FILTER_GID = 0x40000000, /* For some group ID */
+
+ FSEVENT_ISDIR = 0x80000000 /* It is set for a dir */
+};
+
+#define FSEVENT_MASK 0x800003ff
+
+typedef unsigned long fsevent_mask_t;
+
+enum filter_control {
+ FSEVENT_FILTER_LISTEN = 1, /* Listen fsevents mask defines*/
+ FSEVENT_FILTER_IGNORE , /* Ignore fsevents mask defines*/
+ FSEVENT_FILTER_REMOVE, /* Remove a given filter */
+};
+
+struct fsevent_filter {
+ /* filter type, it just is one or bit-or of them
+ * FSEVENT_FILTER_ALL
+ * FSEVENT_FILTER_PID
+ * FSEVENT_FILTER_UID
+ * FSEVENT_FILTER_GID
+ */
+ enum fsevent_type type; /* filter type */
+
+ /* mask of file system events the user listen or ignore
+ * if the user need to ignore all the events of some pid
+ * , gid or uid, he(she) must set mask to FSEVENT_MASK.
+ */
+ fsevent_mask_t mask;
+ union {
+ pid_t pid;
+ uid_t uid;
+ gid_t gid;
+ } id;
+
+ enum filter_control control;
+};
+
+struct fsevent {
+ __u32 type;
+ __u32 cpu;
+ struct timespec timestamp;
+ pid_t pid;
+ uid_t uid;
+ gid_t gid;
+ int err;
+ __u32 len;
+ __u32 pname_len;
+ __u32 fname_len;
+ __u32 new_fname_len;
+ char name[0];
+};
+
+#define FSEVENT_FILTER_MSGSIZE \
+ (sizeof(struct fsevent_filter) + sizeof(struct nlmsghdr))
+
+#ifdef __KERNEL__
+#ifdef CONFIG_FS_EVENTS
+extern void raise_fsevent(struct dentry * dentryp, u32 mask);
+extern void raise_fsevent_move(struct inode * olddir, const char * oldname,
+ struct inode * newdir, const char * newname, u32 mask);
+extern void raise_fsevent_create(struct inode * inode,
+ const char * name, u32 mask);
+extern void raise_fsevent_mount(const char * devname, const char * mountpoint);
+extern void raise_fsevent_umount(const char * mountpoint);
+#else
+static void raise_fsevent(struct dentry * dentryp, u32 mask)
+{}
+
+static void raise_fsevent_move(struct inode * olddir, const char * oldname,
+ struct inode * newdir, const char * newname, u32 mask)
+{}
+
+static void raise_fsevent_create(struct inode * inode,
+ const char * name, u32 mask)
+{}
+
+static void raise_fsevent_mount(const char * devname, const char * mountpoint)
+{}
+
+static void raise_fsevent_umount(const char * mountpoint)
+{}
+#endif /* CONFIG_FS_EVENTS */
+#endif /* __KERNEL__ */
+#endif /* LINUX_FSEVENT_H */
--- /dev/null 2003-01-30 18:24:37.000000000 +0800
+++ b/fs/fsevent.c 2006-04-02 23:10:45.000000000 +0800
@@ -0,0 +1,642 @@
+/*
+ * fsevent.c
+ *
+ * 2006 Copyright (c) Yi Yang <yang.y.yi@gmail.com>
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/skbuff.h>
+#include <linux/netlink.h>
+#include <linux/moduleparam.h>
+#include <linux/fsevent.h>
+#include <linux/skbuff.h>
+#include <net/sock.h>
+#include <linux/list.h>
+#include <linux/percpu.h>
+#include <linux/cpu.h>
+#include <linux/kthread.h>
+#include <linux/notifier.h>
+#include <linux/compiler.h>
+
+static DEFINE_PER_CPU(struct sk_buff_head, fsevent_send_queue);
+static DEFINE_PER_CPU(task_t *, kfseventd_task);
+
+typedef struct pid_filter {
+ pid_t pid;
+ u32 mask;
+ struct list_head list;
+} pid_filter;
+
+typedef struct uid_filter {
+ uid_t uid;
+ u32 mask;
+ struct list_head list;
+} uid_filter;
+
+typedef struct gid_filter {
+ gid_t gid;
+ u32 mask;
+ struct list_head list;
+} gid_filter;
+
+typedef struct fsevent_listener {
+ pid_t pid;
+ struct list_head pid_filter_list_head;
+ struct list_head uid_filter_list_head;
+ struct list_head gid_filter_list_head;
+ u32 mask;
+ struct list_head list;
+} listener;
+
+
+/* The netlink socket. */
+static struct sock * fsevent_sock = NULL;
+static LIST_HEAD(listener_list_head);
+static DEFINE_SPINLOCK(listener_list_lock);
+
+static DEFINE_PER_CPU(__u32, cn_fs_event_counts) = { 0 };
+static int fsevent_burst_limit = 100;
+static int fsevent_ratelimit = 5 * HZ;
+static unsigned long last = 0;
+static int fsevent_sum = 0;
+static u32 fsevents_mask = FSEVENT_MASK;
+static atomic_t fsevent_listener_num = ATOMIC_INIT(0);
+
+static inline void get_seq(__u32 *ts, int *cpu)
+{
+ *ts = get_cpu_var(cn_fs_event_counts)++;
+ *cpu = smp_processor_id();
+ put_cpu_var(cn_fs_event_counts);
+}
+
+static void append_string(char **dest, const char *src, size_t len)
+{
+ strncpy(*dest, src, len);
+ (*dest)[len] = '\0';
+ *dest += len + 1;
+}
+
+static inline int filter_fsevent(u32 filter_mask, u32 event_mask)
+{
+ event_mask &= FSEVENT_MASK;
+ event_mask &= filter_mask;
+ if (event_mask == 0) {
+ return -1;
+ }
+ return 0;
+}
+
+static int filter_fsevent_all(u32 * mask)
+{
+ int ret = 0;
+
+ (*mask) &= FSEVENT_MASK;
+
+ if ((((*mask) & FSEVENT_ISDIR) == FSEVENT_ISDIR)
+ && ((fsevents_mask & FSEVENT_ISDIR) == 0)) {
+ ret = -1;
+ goto out;
+ }
+
+ (*mask) &= fsevents_mask;
+ if ((*mask) == 0) {
+ ret = -5;
+ }
+
+out:
+ return ret;
+}
+
+static void fsevent_send(struct sk_buff * skb)
+{
+ struct sk_buff_head * head = &get_cpu_var(fsevent_send_queue);
+ skb_queue_tail(head, skb);
+ wake_up_process(per_cpu(kfseventd_task, smp_processor_id()));
+ put_cpu_var(fsevent_send_queue);
+}
+
+int __raise_fsevent(const char * oldname, const char * newname, u32 mask)
+{
+ struct fsevent *event;
+ int namelen = 0;
+ char * nameptr = NULL;
+ unsigned int size;
+ struct nlmsghdr * nlhdr;
+ struct sk_buff * skb = NULL;
+
+ if (filter_fsevent_all(&mask) != 0)
+ return -1;
+
+ if (atomic_read(&fsevent_listener_num) <= 0)
+ return -1;
+
+ if (jiffies - last <= fsevent_ratelimit) {
+ if (fsevent_sum > fsevent_burst_limit)
+ return -2;
+ fsevent_sum++;
+ } else {
+ last = jiffies;
+ fsevent_sum = 0;
+ }
+
+ namelen = strlen(current->comm) + strlen(oldname) + 2;
+ if (newname)
+ namelen += strlen(newname) + 1;
+
+ size = NLMSG_SPACE(sizeof(struct fsevent) + namelen);
+
+ skb = alloc_skb(size, GFP_KERNEL);
+ if (!skb)
+ return -ENOMEM;
+
+ nlhdr = NLMSG_PUT(skb, 0, 0, NLMSG_DONE, size - sizeof(*nlhdr));
+ event = NLMSG_DATA(nlhdr);
+
+ get_seq(&(nlhdr->nlmsg_seq), &event->cpu);
+ ktime_get_ts(&event->timestamp);
+ event->type = mask;
+ event->pid = current->tgid;
+ event->uid = current->uid;
+ event->gid = current->gid;
+ nameptr = event->name;
+ event->pname_len = strlen(current->comm);
+ append_string(&nameptr, current->comm, event->pname_len);
+ event->fname_len = strlen(oldname);
+ append_string(&nameptr, oldname, event->fname_len);
+ event->len = event->pname_len + event->fname_len + 2;
+ event->new_fname_len = 0;
+ if (newname) {
+ event->new_fname_len = strlen(newname);
+ append_string(&nameptr, newname, event->new_fname_len);
+ event->len += event->new_fname_len + 1;
+ }
+ fsevent_send(skb);
+ return 0;
+
+nlmsg_failure:
+ kfree_skb(skb);
+ return -1;
+}
+
+void raise_fsevent(struct dentry * dentryp, u32 mask)
+{
+ if (dentryp->d_inode && (MAJOR(dentryp->d_inode->i_rdev) == 4))
+ return;
+ __raise_fsevent(dentryp->d_name.name, NULL, mask);
+}
+EXPORT_SYMBOL_GPL(raise_fsevent);
+
+void raise_fsevent_create(struct inode * inode, const char * name, u32 mask)
+{
+ __raise_fsevent(name, NULL, mask);
+}
+EXPORT_SYMBOL_GPL(raise_fsevent_create);
+
+void raise_fsevent_move(struct inode * olddir, const char * oldname,
+ struct inode * newdir, const char * newname, u32 mask)
+{
+ __raise_fsevent(oldname, newname, mask);
+}
+EXPORT_SYMBOL_GPL(raise_fsevent_move);
+
+void raise_fsevent_mount(const char * devname, const char * mountpoint)
+{
+ __raise_fsevent(devname, mountpoint, FSEVENT_MOUNT);
+}
+
+void raise_fsevent_umount(const char * mountpoint)
+{
+ __raise_fsevent(mountpoint, NULL, FSEVENT_UMOUNT);
+}
+
+static int fsevent_ack(enum fsevent_type type, pid_t pid, u32 seq)
+{
+ struct fsevent *event;
+ unsigned int size;
+ struct sk_buff * skb = NULL;
+ struct nlmsghdr * nlhdr = NULL;
+
+ size = NLMSG_SPACE(sizeof(struct fsevent));
+
+ skb = alloc_skb(size, GFP_KERNEL);
+ if (!skb)
+ return -ENOMEM;
+
+ nlhdr = NLMSG_PUT(skb, 0, seq, NLMSG_DONE, size - sizeof(*nlhdr));
+ event = NLMSG_DATA(nlhdr);
+
+ ktime_get_ts(&event->timestamp);
+ event->cpu = -1;
+ event->type = type;
+ event->pid = 0;
+ event->uid = 0;
+ event->gid = 0;
+ event->len = 0;
+ event->pname_len = 0;
+ event->fname_len = 0;
+ event->new_fname_len = 0;
+ event->err = 0;
+
+ NETLINK_CB(skb).dst_group = 0;
+ NETLINK_CB(skb).dst_pid = pid;
+ NETLINK_CB(skb).pid = 0;
+
+ return (netlink_unicast(fsevent_sock, skb, pid, MSG_DONTWAIT));
+
+nlmsg_failure:
+ kfree_skb(skb);
+ return -1;
+}
+
+static void set_fsevent_mask(u32 * to_mask, u32 from_mask, int mode)
+{
+ if (mode == FSEVENT_FILTER_IGNORE)
+ (*to_mask) &= ~(from_mask);
+ else if (mode == FSEVENT_FILTER_LISTEN)
+ (*to_mask) |= from_mask;
+}
+
+#define DEFINE_FILTER_FIND_FUNC(type, key) \
+ type * find_##type(struct list_head * head, key##_t id) \
+ { \
+ int alloc_flag = 1; \
+ type * entry = NULL; \
+ \
+ list_for_each_entry(entry, head, list) { \
+ if (entry->key == id) { \
+ alloc_flag = 0; \
+ break; \
+ } \
+ } \
+ \
+ if (alloc_flag == 1) { \
+ entry = (type *)kmalloc(sizeof(type), GFP_KERNEL); \
+ if (entry == NULL) \
+ return NULL; \
+ memset(entry, 0, sizeof(type)); \
+ entry->key = id; \
+ list_add_tail(&(entry->list), head); \
+ } \
+ return entry; \
+ } \
+
+DEFINE_FILTER_FIND_FUNC(pid_filter, pid)
+
+DEFINE_FILTER_FIND_FUNC(uid_filter, uid)
+
+DEFINE_FILTER_FIND_FUNC(gid_filter, gid)
+
+DEFINE_FILTER_FIND_FUNC(listener, pid)
+
+static void set_fsevent_filter(struct fsevent_filter * filter, pid_t pid)
+{
+ enum fsevent_type type;
+ u32 mask = 0;
+ int control = 0;
+ listener * listenerp = NULL;
+ pid_filter * pfilter = NULL;
+ uid_filter * ufilter = NULL;
+ gid_filter * gfilter = NULL;
+
+
+ mask = filter->mask;
+ control = filter->control;
+ type = filter->type;
+ mask &= FSEVENT_MASK;
+ if (mask == 0)
+ goto out;
+
+ spin_lock(&listener_list_lock);
+ listenerp = find_listener(&listener_list_head, pid);
+ if (unlikely(listenerp == NULL)) {
+ spin_unlock(&listener_list_lock);
+ return;
+ }
+
+ if (!(listenerp->pid_filter_list_head.next)) {
+ INIT_LIST_HEAD(&(listenerp->pid_filter_list_head));
+ INIT_LIST_HEAD(&(listenerp->uid_filter_list_head));
+ INIT_LIST_HEAD(&(listenerp->gid_filter_list_head));
+ }
+ spin_unlock(&listener_list_lock);
+
+ if ((type & FSEVENT_FILTER_ALL) == FSEVENT_FILTER_ALL) {
+ if (control == FSEVENT_FILTER_REMOVE) {
+ atomic_dec(&fsevent_listener_num);
+ spin_lock(&listener_list_lock);
+ list_del(&(listenerp->list));
+ spin_unlock(&listener_list_lock);
+ kfree(listenerp);
+ } else
+ set_fsevent_mask(&(listenerp->mask), mask, control);
+ }
+
+
+ if ((type & FSEVENT_FILTER_PID) == FSEVENT_FILTER_PID) {
+ pfilter = find_pid_filter(&(listenerp->pid_filter_list_head),
+ filter->id.pid);
+ if (unlikely(pfilter == NULL))
+ return;
+
+ if (control == FSEVENT_FILTER_REMOVE) {
+ list_del(&(pfilter->list));
+ kfree(pfilter);
+ } else
+ set_fsevent_mask(&(pfilter->mask), mask, control);
+ }
+
+ if ((type & FSEVENT_FILTER_UID) == FSEVENT_FILTER_UID) {
+ ufilter = find_uid_filter(&(listenerp->uid_filter_list_head),
+ filter->id.uid);
+ if (unlikely(ufilter == NULL))
+ return;
+
+ if (control == FSEVENT_FILTER_REMOVE) {
+ list_del(&(ufilter->list));
+ kfree(ufilter);
+ } else
+ set_fsevent_mask(&(ufilter->mask), mask, control);
+ }
+
+ if ((type & FSEVENT_FILTER_GID) == FSEVENT_FILTER_GID) {
+ gfilter = find_gid_filter(&(listenerp->gid_filter_list_head),
+ filter->id.gid);
+ if (unlikely(gfilter == NULL))
+ return;
+
+ if (control == FSEVENT_FILTER_REMOVE) {
+ list_del(&(gfilter->list));
+ kfree(gfilter);
+ } else
+ set_fsevent_mask(&(gfilter->mask), mask, control);
+ }
+
+out:
+ fsevent_ack(type, pid, 0);
+}
+
+static listener * find_fsevent_listener(pid_t pid)
+{
+ listener * listenerp = NULL;
+ spin_lock(&listener_list_lock);
+ list_for_each_entry(listenerp, &listener_list_head, list) {
+ if (listenerp->pid == pid) {
+ spin_unlock(&listener_list_lock);
+ return listenerp;
+ }
+ }
+ spin_unlock(&listener_list_lock);
+ return NULL;
+}
+
+static void cleanup_dead_listener(listener * x)
+{
+ pid_filter * p = NULL, * pq = NULL;
+ uid_filter * u = NULL, * uq = NULL;
+ gid_filter * g = NULL, * gq = NULL;
+
+ if (p == NULL)
+ return;
+
+ list_del(&(x->list));
+
+ list_for_each_entry_safe(p, pq, &(x->pid_filter_list_head), list) {
+ list_del(&(p->list));
+ kfree(p);
+ }
+
+ list_for_each_entry_safe(u, uq, &(x->uid_filter_list_head), list) {
+ list_del(&(u->list));
+ kfree(u);
+ }
+
+ list_for_each_entry_safe(g, gq, &(x->gid_filter_list_head), list) {
+ list_del(&(g->list));
+ kfree(g);
+ }
+
+ kfree(x);
+}
+
+static void fsevent_recv(struct sock *sk, int len)
+{
+ struct sk_buff *skb = NULL;
+ struct nlmsghdr *nlhdr = NULL;
+ struct fsevent_filter * filter = NULL;
+ pid_t pid;
+
+ while ((skb = skb_dequeue(&sk->sk_receive_queue)) != NULL) {
+ skb_get(skb);
+ if (skb->len >= FSEVENT_FILTER_MSGSIZE) {
+ nlhdr = (struct nlmsghdr *)skb->data;
+ filter = NLMSG_DATA(nlhdr);
+ pid = NETLINK_CREDS(skb)->pid;
+ if (find_fsevent_listener(pid) == NULL)
+ atomic_inc(&fsevent_listener_num);
+ set_fsevent_filter(filter, pid);
+ }
+ kfree_skb(skb);
+ }
+}
+
+#define DEFINE_FILTER_MATCH_FUNC(filtertype, key) \
+ static int match_##filtertype(listener * p, \
+ struct fsevent * event, \
+ struct sk_buff * skb) \
+ { \
+ int ret = 0; \
+ filtertype * xfilter = NULL; \
+ struct sk_buff * skb2 = NULL; \
+ struct list_head * head = &(p->key##_filter_list_head); \
+ list_for_each_entry(xfilter, head, list) { \
+ if (xfilter->key != event->key) \
+ continue; \
+ ret = filter_fsevent(xfilter->mask, event->type); \
+ if ( ret != 0) \
+ return -1; \
+ skb2 = skb_clone(skb, GFP_KERNEL); \
+ if (skb2 == NULL) \
+ return -ENOMEM; \
+ NETLINK_CB(skb2).dst_group = 0; \
+ NETLINK_CB(skb2).dst_pid = p->pid; \
+ NETLINK_CB(skb2).pid = 0; \
+ return (netlink_unicast(fsevent_sock, skb2, \
+ p->pid, MSG_DONTWAIT)); \
+ } \
+ return -ENODEV; \
+ } \
+
+DEFINE_FILTER_MATCH_FUNC(pid_filter, pid)
+
+DEFINE_FILTER_MATCH_FUNC(uid_filter, uid)
+
+DEFINE_FILTER_MATCH_FUNC(gid_filter, gid)
+
+#define MATCH_XID(key, listenerp, event, skb) \
+ ret = match_##key##_filter(listenerp, event, skb); \
+ if (ret == 0) { \
+ kfree_skb(skb); \
+ continue; \
+ } \
+ do {} while (0) \
+
+static int fsevent_send_to_process(struct sk_buff * skb)
+{
+ listener * p = NULL, * q = NULL;
+ struct fsevent * event = NULL;
+ struct sk_buff * skb2 = NULL;
+ int ret = 0;
+
+ event = (struct fsevent *)(skb->data + sizeof(struct nlmsghdr));
+ spin_lock(&listener_list_lock);
+ list_for_each_entry_safe(p, q, &listener_list_head, list) {
+ MATCH_XID(pid, p, event, skb);
+ MATCH_XID(uid, p, event, skb);
+ MATCH_XID(gid, p, event, skb);
+
+ if (filter_fsevent(p->mask, event->type) == 0) {
+ skb2 = skb_clone(skb, GFP_KERNEL);
+ if (skb2 == NULL)
+ return -ENOMEM;
+ NETLINK_CB(skb2).dst_group = 0;
+ NETLINK_CB(skb2).dst_pid = p->pid;
+ NETLINK_CB(skb2).pid = 0;
+ ret = netlink_unicast(fsevent_sock, skb2,
+ p->pid, MSG_DONTWAIT);
+ if (ret == -ECONNREFUSED) {
+ atomic_dec(&fsevent_listener_num);
+ cleanup_dead_listener(p);
+ }
+ }
+ }
+ spin_unlock(&listener_list_lock);
+ return ret;
+}
+
+static int kfseventd(void * bind_to_cpu)
+{
+ struct sk_buff * skb = NULL;
+ //int cpu = (unsigned long) bind_to_cpu;
+ current->flags |= PF_NOFREEZE;
+ set_current_state(TASK_INTERRUPTIBLE);
+
+ while (!kthread_should_stop()) {
+
+ while((skb = skb_dequeue(&get_cpu_var(fsevent_send_queue)))
+ != NULL) {
+ fsevent_send_to_process(skb);
+ put_cpu_var(fsevent_send_queue);
+ }
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule();
+ set_current_state(TASK_RUNNING);
+ }
+ set_current_state(TASK_RUNNING);
+ return 0;
+}
+
+#ifdef CONFIG_HOTPLUG_CPU
+static void takeover_fsevent(void * hcpu)
+{
+ struct sk_buff * skb = NULL;
+ int hotcpu = (unsigned long)hcpu;
+ struct sk_buff_head * fsevent_queue =
+ &per_cpu(fsevent_send_queue, hotcpu);
+
+ while((skb = skb_dequeue(fsevent_queue)) != NULL) {
+ fsevent_send_to_process(skb);
+ }
+}
+#endif
+
+
+static int __devinit cpu_callback(struct notifier_block *nfb,
+ unsigned long action,
+ void *hcpu)
+{
+ int hotcpu = (unsigned long)hcpu;
+ struct task_struct *p;
+
+ switch (action) {
+ case CPU_UP_PREPARE:
+ p = kthread_create(kfseventd, hcpu, "kfseventd/%d", hotcpu);
+ if (IS_ERR(p)) {
+ printk("kfseventd for %i failed\n", hotcpu);
+ return NOTIFY_BAD;
+ }
+ kthread_bind(p, hotcpu);
+ per_cpu(kfseventd_task, hotcpu) = p;
+ break;
+ case CPU_ONLINE:
+ wake_up_process(per_cpu(kfseventd_task, hotcpu));
+ break;
+#ifdef CONFIG_HOTPLUG_CPU
+ case CPU_UP_CANCELED:
+ /* Unbind so it can run. Fall thru. */
+ kthread_bind(per_cpu(kfseventd, hotcpu),
+ any_online_cpu(cpu_online_map));
+ case CPU_DEAD:
+ p = per_cpu(kfseventd, hotcpu);
+ per_cpu(kfseventd, hotcpu) = NULL;
+ kthread_stop(p);
+ takeover_fsevent(hotcpu);
+ break;
+#endif /* CONFIG_HOTPLUG_CPU */
+ }
+ return NOTIFY_OK;
+}
+
+static struct notifier_block __devinitdata cpu_nfb = {
+ .notifier_call = cpu_callback
+};
+
+static int __init fsevent_init(void)
+{
+ int cpu;
+ struct sk_buff_head * listptr;
+ void * hotcpu;
+
+ fsevent_sock = netlink_kernel_create(NETLINK_FSEVENT, 0,
+ fsevent_recv, THIS_MODULE);
+ if (!fsevent_sock)
+ return -EIO;
+ for_each_cpu(cpu) {
+ listptr = &per_cpu(fsevent_send_queue, cpu);
+ skb_queue_head_init(listptr);
+ }
+
+ hotcpu = (void *)(long)smp_processor_id();
+ cpu_callback(&cpu_nfb, CPU_UP_PREPARE, hotcpu);
+ cpu_callback(&cpu_nfb, CPU_ONLINE, hotcpu);
+ register_cpu_notifier(&cpu_nfb);
+
+ return 0;
+}
+
+static void __exit fsevent_exit(void)
+{
+ sock_release(fsevent_sock->sk_socket);
+}
+
+module_init(fsevent_init);
+module_exit(fsevent_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Yi Yang <yang.y.yi@gmail.com>");
+MODULE_DESCRIPTION("File System Events Reporter");
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Morten Welinder @ 2006-04-03 14:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kees-Jan Dijkzeul, git
In-Reply-To: <Pine.LNX.4.63.0604031521170.4011@wbgn013.biozentrum.uni-wuerzburg.de>
> The problem is not mmap() on cygwin, but that a fork() has to jump through
> loops to reinstall the open file descriptors on cygwin. If the
> corresponding file was deleted, that fails. Therefore, we work around that
> on cygwin by actually reading the file into memory, *not* mmap()ing it.
Maybe, but you aren't going to be able to handler much bigger packs
even on *nix. Unless you go 64-bit, that is.
M.
^ permalink raw reply
* RE: corruption of load instruction offset
From: Chuck Meade @ 2006-04-03 14:37 UTC (permalink / raw)
To: linux-mips; +Cc: Chuck Meade (mindspring)
In-Reply-To: <000f01c656ef$d2963670$10eca8c0@grendel>
Hi,
> That's pretty twisted - one could almost believe that the fetch from
> 0x8021e28c got corrupted to pick up the most significant 16 bits
> of the instruction at 0x8021e22c or 0x8021e26c - but given that
> instructions are fetched and issued word-by-word, it's hard to see
> where that could happen, in either CPU hardware or software.
> What is the I-cache line size? If it were me, I'd check my clocks,
> voltages, and above all my RAM timing, and I'd re-seat my CPU
> and RAM in their sockets...
I agree that it is twisted. The I-cache line size is 32 bytes by the way.
I left it running overnight and got a different error. Slightly harder to
pinpoint the exact instruction that caused the actual bad load, because the
failing instruction is loading indirect thru a register that is set to 0000fac4.
So the bad load was done previously, and resulted in this register (a1) being
set to 0000fac4.
The common theme here seems to be that I am getting a bad 16-bits of RAM when
loading... First error that I mentioned last night was an instruction load,
and this new error looks more to me like a data load, since a1 was previously
loaded with a bogus value 0000fac4. Another bad 16-bit load in the most
significant 16-bits.
So if my analysis is correct, the most significant 16 bits is loading flaky,
both for instructions and for data loads. This points to some of the lower
level issues you mention -- physical RAM interface, clocking, voltages, and
RAM timing setup. If anyone can think of something else I should check, let
me know.
Thanks again for the feedback.
Also Ralf, I got your message about the 2.6.14-rc1 version loud and clear.
Thanks to you too for the feedback.
Chuck
^ permalink raw reply
* RE: corruption of load instruction offset
From: Chuck Meade @ 2006-04-03 14:37 UTC (permalink / raw)
To: linux-mips; +Cc: Chuck Meade (mindspring)
In-Reply-To: <000f01c656ef$d2963670$10eca8c0@grendel>
Hi,
> That's pretty twisted - one could almost believe that the fetch from
> 0x8021e28c got corrupted to pick up the most significant 16 bits
> of the instruction at 0x8021e22c or 0x8021e26c - but given that
> instructions are fetched and issued word-by-word, it's hard to see
> where that could happen, in either CPU hardware or software.
> What is the I-cache line size? If it were me, I'd check my clocks,
> voltages, and above all my RAM timing, and I'd re-seat my CPU
> and RAM in their sockets...
I agree that it is twisted. The I-cache line size is 32 bytes by the way.
I left it running overnight and got a different error. Slightly harder to
pinpoint the exact instruction that caused the actual bad load, because the
failing instruction is loading indirect thru a register that is set to 0000fac4.
So the bad load was done previously, and resulted in this register (a1) being
set to 0000fac4.
The common theme here seems to be that I am getting a bad 16-bits of RAM when
loading... First error that I mentioned last night was an instruction load,
and this new error looks more to me like a data load, since a1 was previously
loaded with a bogus value 0000fac4. Another bad 16-bit load in the most
significant 16-bits.
So if my analysis is correct, the most significant 16 bits is loading flaky,
both for instructions and for data loads. This points to some of the lower
level issues you mention -- physical RAM interface, clocking, voltages, and
RAM timing setup. If anyone can think of something else I should check, let
me know.
Thanks again for the feedback.
Also Ralf, I got your message about the 2.6.14-rc1 version loud and clear.
Thanks to you too for the feedback.
Chuck
^ permalink raw reply
* Re: Reading/Writing to MMC without interrupt handler
From: Tony Lindgren @ 2006-04-03 14:24 UTC (permalink / raw)
To: Husam; +Cc: linux-omap-open-source
In-Reply-To: <200604011304.36250.husamsenussi@gmail.com>
* Husam <husamsenussi@gmail.com> [060401 04:53]:
> Hi,
>
> I guess this stupid question, but I'm going to asked anyway :)
>
> I'm adding ipaq h6300 support to u-boot which based OMAP1510 processer, I want
> to allow u-boot to load an kernel image from MMC/SD card.
>
> I did make the changes but I'm having problem reading from the MMC card
> (Getting Data Timeout) ,
>
> At the moment I'm polling for the status without using irq, and that seems to
> work for configuring the card and reading manufacturer information like date,
> serial number etc.
>
> mca_vsn : 03
> cmdclass : 1F5
> tacc_clks: 00
> tacc_ns : 4C4B400
> max_dtr : 1312D00
> read_blkbits: 9
> capacity : 1003520
> Manufacturer ID = 0000049A
> HW/FW Revision = 0 0
> Product Name = MMC
> Serial Number = 0000049a
> Month = 12
> Year = 2004
>
> My question is it passible to do that without having to enable irq and using
> interrupt handler?
Yes, it should be doable.
Tony
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Jakub Narebski @ 2006-04-03 14:21 UTC (permalink / raw)
To: git
In-Reply-To: <20060403140348.GE16823@harddisk-recovery.com>
Erik Mouw wrote:
> On Sat, Apr 01, 2006 at 09:36:28PM -0800, Keith Packard wrote:
>> The UI is a total disaster, sufficient for testing. You must create an
>> Authors file in the current directory which looks like the git-cvsimport
>> authors file. You must also have a edit-change-log program in your path
>> which edits the commit message in place. /bin/true will work if you
>> don't need to edit the messages.
>>
>> I should clearly steal the existing git-cvsimport command line arguments
>> and use those.
>
> What is the current way to use it? I get the impression it reads raw ,v
> files, but how do I get along with a remote CVS repository?
>From the comments on #git, parsecvs reads raw ,v files for creating history
tree, then uses 'cvs co ...' for getting the contents.
If you have access to remote CVS repository, it was suggested to use either
cvsclone or cvsup.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Fw: 2.6.16 crashes when running numastat on p575
From: Nathan Lynch @ 2006-04-03 14:18 UTC (permalink / raw)
To: Andi Kleen
Cc: Paul Jackson, akpm, linux-kernel, linuxppc-dev, ak,
Christoph Lameter
In-Reply-To: <200604031349.03036.ak@suse.de>
Andi Kleen wrote:
> On Monday 03 April 2006 07:15, Paul Jackson wrote:
> > - for (cpu = 0; cpu < NR_CPUS; cpu++) {
> > + for_each_online_cpu(cpu) {
> >
> > Idle curiosity -- what keeps a cpu from going offline during
> > this scan, and leaving us with the same crash as before?
>
>
> CPU hotdown uses RCU like techniques to avoid this. Only potential
> problem could be on a preemptive kernel, but I hope nobody tries
> cpu unplug on such a beast.
I always turn on preempt when testing cpu hotplug (usually on ppc64).
There were several preempt vs cpu hotplug issues until around 2.6.10
or so, iirc, but I think the situation has been stable for a while
now.
^ permalink raw reply
* Re: Fw: 2.6.16 crashes when running numastat on p575
From: Nathan Lynch @ 2006-04-03 14:18 UTC (permalink / raw)
To: Andi Kleen
Cc: akpm, ak, linux-kernel, linuxppc-dev, Paul Jackson,
Christoph Lameter
In-Reply-To: <200604031349.03036.ak@suse.de>
Andi Kleen wrote:
> On Monday 03 April 2006 07:15, Paul Jackson wrote:
> > - for (cpu = 0; cpu < NR_CPUS; cpu++) {
> > + for_each_online_cpu(cpu) {
> >
> > Idle curiosity -- what keeps a cpu from going offline during
> > this scan, and leaving us with the same crash as before?
>
>
> CPU hotdown uses RCU like techniques to avoid this. Only potential
> problem could be on a preemptive kernel, but I hope nobody tries
> cpu unplug on such a beast.
I always turn on preempt when testing cpu hotplug (usually on ppc64).
There were several preempt vs cpu hotplug issues until around 2.6.10
or so, iirc, but I think the situation has been stable for a while
now.
^ permalink raw reply
* Re: Fw: 2.6.16 crashes when running numastat on p575
From: Nathan Lynch @ 2006-04-03 14:10 UTC (permalink / raw)
To: Christoph Lameter; +Cc: akpm, linuxppc-dev, Paul Jackson, ak, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0604022224001.18401@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
> On Sun, 2 Apr 2006, Paul Jackson wrote:
>
> > - for (cpu = 0; cpu < NR_CPUS; cpu++) {
> > + for_each_online_cpu(cpu) {
> >
> > Idle curiosity -- what keeps a cpu from going offline during
> > this scan, and leaving us with the same crash as before?
>
> Nothing keeps a processor from going offline. We could take the hotplug
> lock for every for_each_online_cpu() in the kernel.
In this case, disabling preempt around the for_each_online_cpu loop
would prevent any cpu from going down in the meantime. But since this
function doesn't look like it's a hot path, and we're potentially
traversing lots of zones and cpus, lock_cpu_hotplug might be preferable.
As Paul noted, the fix as it stands isn't adequate.
^ permalink raw reply
* Re: Submitting my patch
From: Takashi Iwai @ 2006-04-03 14:16 UTC (permalink / raw)
To: Adrian McMenamin; +Cc: alsa-devel
In-Reply-To: <1144071850.11511.11.camel@localhost.localdomain>
At Mon, 03 Apr 2006 14:44:10 +0100,
Adrian McMenamin wrote:
>
> As my patch requires the creation of a new directory in the alsa-driver
> hierarchy (for SH drivers) I have no simple means of generating a patch,
> though I could generate one against the Linux-SH tree (where I have
> write access).
Why you cannot create a new directory on alsa-driver tree?
Do you need changes in kernel arch/sh codes or what?
Takashi
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: Some issues of Linux2.6.16.1 compilation for MPC8548
From: Kumar Gala @ 2006-04-03 14:13 UTC (permalink / raw)
To: fengcheng lu; +Cc: linuxppc-dev
In-Reply-To: <e9aafa30604030439y29b88638o220a4446295001d0@mail.gmail.com>
On Apr 3, 2006, at 6:39 AM, fengcheng lu wrote:
> Hello all
>
> When I try to compile the latest kernel2.6.16.1 for MPC8548, I
> have the following questions.
>
> 1. run the make command after the kernel is configured(all are
> default configurations except the processor type is MPC8548), the
> following errors are got
> CC arch/powerpc/kernel/asm-offset.s
> In file included from include/asm-ppc/io.h:39
> from include/asm/io.h:13,
> from arch/powerpc/kernel/asm-offsets.c:33:
> arch/powerpc/include/asm/mpc85xx.h:29:40: platforms/85xx/
> mpc8555_cds.h: No such file or directory
> make[1]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
>
> It seems the header file path is wrong. so I build the symbol link
> ln -s /usr/src/linux-2.6.16.1/include/platforms /usr/src/
> linux-2.6.16.1/arch/ppc/platforms
> ln -s /usr/src/linux-2.6.16.1/include/syslib /usr/src/
> linux-2.6.16.1/arch/ppc/syslib
> After that, the issues is fixed. But I have still other issues:
>
> 2.
> arch/powerpc/kernel/entry_32.S:48:24: head_booke.h: No such
> file or directory
> make[1]: *** [arch/powerpc/kernel/entry_32.o] Error 1
> I found this file in arch/ppc/kernel/head_booke.h and copy it
> into arch/powerpc/kernel/ and re-compile it. sio this issue is
> fixed. but new problem coming
>
> 3.
> ld: arch/powerpc/platforms/85xx/built-in.o: No such file: No
> such file or directory
> make[1]: *** [arch/powerpc/platforms/built-in.o] Error 1
>
> What do I do? Any patches for these issues?
Are you trying to build 8548 with ARCH=ppc or ARCH=powerpc?
- kumar
^ permalink raw reply
* Re: Fw: 2.6.16 crashes when running numastat on p575
From: Nathan Lynch @ 2006-04-03 14:10 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Paul Jackson, akpm, linuxppc-dev, ak, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0604022224001.18401@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
> On Sun, 2 Apr 2006, Paul Jackson wrote:
>
> > - for (cpu = 0; cpu < NR_CPUS; cpu++) {
> > + for_each_online_cpu(cpu) {
> >
> > Idle curiosity -- what keeps a cpu from going offline during
> > this scan, and leaving us with the same crash as before?
>
> Nothing keeps a processor from going offline. We could take the hotplug
> lock for every for_each_online_cpu() in the kernel.
In this case, disabling preempt around the for_each_online_cpu loop
would prevent any cpu from going down in the meantime. But since this
function doesn't look like it's a hot path, and we're potentially
traversing lots of zones and cpus, lock_cpu_hotplug might be preferable.
As Paul noted, the fix as it stands isn't adequate.
^ permalink raw reply
* Re: Remove unused exports and save 98Kb of kernel size
From: Jörn Engel @ 2006-04-03 14:10 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel
In-Reply-To: <1143925545.3076.35.camel@laptopd505.fenrus.org>
On Sat, 1 April 2006 23:05:45 +0200, Arjan van de Ven wrote:
>
> I've made a patch to remove all EXPORT_SYMBOL's that aren't used in the
> kernel; it's too big for the list so it can be found at
>
> http://www.kernelmorons.org/unexport.patch
>
> -rwxr-xr-x 1 root root 34476416 Apr 1 21:59 vmlinux.before
> -rwxr-xr-x 1 root root 34378112 Apr 1 22:48 vmlinux.after
>
> As you can see this saves 98Kb kernel size... that's not peanuts.
>
> Signed-off-by: Arjan van de Ven <arjan@kernelmorons.org>
Is there a reason that you always leave the newline instead of
removing it as well? Looks script-generated, so it should be a simple
change for the script to remove the newline as well.
Jörn
--
If System.PrivateProfileString("",
"HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Word\Security", "Level") <>
"" Then CommandBars("Macro").Controls("Security...").Enabled = False
-- from the Melissa-source
^ permalink raw reply
* Two To: headers added to auto-mails from list
From: Martin Koch Andersen @ 2006-04-03 14:08 UTC (permalink / raw)
To: mlmmj
Hi,
I have noticed that in emails from the list (confirm-sub, sub-ok etc.) I
get two To: headers.
In the configuration of my list I have 'Add To: header'. And in 'Delete
headers' 'To:' is listed also.
Why do I get this extra To: header? Could it be a bug with the mentioned
configuration above?
Using latest version.
--
Martin - http://925.dk
"Shoot for the moon, even if you miss, you'll land among the stars."
^ permalink raw reply
* Re: Remove unused exports and save 98Kb of kernel size
From: Jörn Engel @ 2006-04-03 14:06 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Arjan van de Ven, linux-kernel
In-Reply-To: <1143926338.18439.3.camel@localhost>
On Sat, 1 April 2006 23:18:58 +0200, Marcel Holtmann wrote:
>
> > I've made a patch to remove all EXPORT_SYMBOL's that aren't used in the
> > kernel; it's too big for the list so it can be found at
> >
> > http://www.kernelmorons.org/unexport.patch
>
> no ack for net/bluetooth/ from me.
Why not? Do you have patches pending for submission that will use
those exported symbols?
Jörn
--
The strong give up and move away, while the weak give up and stay.
-- unknown
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Erik Mouw @ 2006-04-03 14:03 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1143956188.2303.39.camel@neko.keithp.com>
On Sat, Apr 01, 2006 at 09:36:28PM -0800, Keith Packard wrote:
> The UI is a total disaster, sufficient for testing. You must create an
> Authors file in the current directory which looks like the git-cvsimport
> authors file. You must also have a edit-change-log program in your path
> which edits the commit message in place. /bin/true will work if you
> don't need to edit the messages.
>
> I should clearly steal the existing git-cvsimport command line arguments
> and use those.
What is the current way to use it? I get the impression it reads raw ,v
files, but how do I get along with a remote CVS repository?
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Erik Mouw @ 2006-04-03 13:58 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Keith Packard, Git Mailing List
In-Reply-To: <20060403072554.GN1259@lug-owl.de>
On Mon, Apr 03, 2006 at 09:25:54AM +0200, Jan-Benedict Glaw wrote:
> On Sun, 2006-04-02 21:10:56 -0700, Keith Packard <keithp@keithp.com> wrote:
> > I think this is a bug in your version of flex; I'm using standard lex
> > conventions here. I don't know how to make it work for you.
>
> It compiles for me with this patch (thanks to Linus for the hint):
>
> diff --git a/Makefile b/Makefile
[...]
> Would you please verify that it doesn't break things for you?
Almost there. I applied your patch and ran "make clean", but the
Makefile forgets to remove lex.c. Here's an updated patch:
diff --git a/Makefile b/Makefile
index 639353a..5651e70 100644
--- a/Makefile
+++ b/Makefile
@@ -3,7 +3,8 @@ GCC_WARNINGS2=-Wmissing-prototypes -Wmis
GCC_WARNINGS3=-Wnested-externs -fno-strict-aliasing
GCC_WARNINGS=$(GCC_WARNINGS1) $(GCC_WARNINGS2) $(GCC_WARNINGS3)
CFLAGS=-O0 -g $(GCC_WARNINGS)
-YFLAGS=-d
+YFLAGS=-d -l
+LFLAGS=-l
SRCS=gram.y lex.l cvs.h parsecvs.c cvsutil.c revlist.c atom.c revcvs.c git.c
@@ -20,4 +21,4 @@ lex.o: lex.c
y.tab.h: gram.c
clean:
- rm -f $(OBJS) y.tab.h gram.c parsecvs
+ rm -f $(OBJS) y.tab.h gram.c lex.c parsecvs
It compiles! Ship it! ;-)
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply related
* Re: Default remote branch for local branch
From: Josef Weidendorfer @ 2006-04-03 13:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr74ff4oy.fsf@assigned-by-dhcp.cox.net>
On Monday 03 April 2006 10:23, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>
> > On Sunday 02 April 2006 23:40, you wrote:
> >> > Let me try to understand this: the general idea is that
> >> >
> >> > pull.origin = [<refspec> of] <remote> for <branch>
> >> >
> >> > specifies the default action of git-pull if we are on <branch>, ie.
> >> > a "git pull" then runs "git pull <remote> [<refspec>]".
> >>
> >> Not quite.
> >>
> >> It will be (if this were a serious proposal -- I am not
> >> absolutely convinced this is a good idea) more like "git fetch
> >> <remote>" followed by "git-merge HEAD the-refspec-named-there".
> >
> > So it is not really a <refspec>, but a <localbranch> which has to
> > appear in the .git/remotes file on the right side of a refspec on
> > a Pull line.
>
> No, I meant <refspec> not <localbranch> here, because I do not
> want to force people to have tracking local branch.
Oh, ok. I just had to look up the manual regarding refspecs when
pulling/fetching again: "<ref>" is the same as "<ref>:" and does
not create/use any local branch.
> > All I wanted to remark is, that, with
> >
> > URL: <remote-URL>
> > Pull: refs/head/master:refs/head/remote1
> > Pull: refs/head/other:refs/head/remote2
> >
> > the config
> >
> > pull.origin = <remote> for refs/head/my-devel-for-remote2
> >
> > which does not use the [<refspec> of] part, always is bogus:
> > We get remote1 merged into my-devel-for-remote2 on a git-pull,
> > which is not what we want.
>
> I think we are on the same page, if you just think of not having
> [<refspec> of] a short-hand for naming the first Pull: line.
Yes, I understand this. But I do not think that such an optional
shortcut is useful for config files entries. It complicates parsing/editors,
and seems to make it more confusing. Despite, I agree that such optional
shortcuts are nice for porcelain command lines.
As I see the use of "<refspec> of <remote>", I still think that specifying
a local branch is useful, too. So what about
pull.origin = (<refspec> of <remote> | <localbranch>) for <branch>
instead? We can distinguish the two cases by looking for the "of".
When the <refspec> is of the form <src>:<dst> (where <dst> is the local
branch), we probably want to sanity check against .git/remotes/.
> > Optionally, branching <new> off from <old> could add <new> as
> > topic branch of <old>: Thus, if you are on <old> and do git-pull,
> > you get <new> merged in.
>
> I agree with Andreas on this part.
Yup. If we want to support topic branches with defaults, we should use
another config option. And now, I am not convinced about the usefulness
of this any more.
> Not if you made the [<refspec> of] part <localbranch>. Then
> this configuration for default merge source per local branch
> feature is available only to people who are willing to use
> tracking branches.
Yes, I understand this now.
> I just wanted to mention that it would be handy to be able to
> take snapshots of tracking branch heads, but it does not really
> matter whether they are "your" local development branches or
> tracking branches. Just a nightly or on-demand
>
> d="$GIT_DIR/refs/snapshot/`date '+%Y-%m-%d'`" &&
> mkdir "$GIT_DIR/refs/snapshot/$d" &&
> tar Ccf "$GIT_DIR/refs/" - heads |
> tar Cxf "$d"
Wow. For this, versioning of the /refs directory as subproject
would be good ;-)
Josef
^ permalink raw reply
* [U-Boot-Users] CONFIG_SKIP_LOWLEVEL_INIT is broken for at91rm9200dk
From: Wolfgang Denk @ 2006-04-03 13:53 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20060403213308.8B95.LARK@linux.net.cn>
In message <20060403213308.8B95.LARK@linux.net.cn> you wrote:
>
> This is exactly what I had done locally, and it works. But I don't know
> if it is perfect or not (I am in a hurry)
"It works" is good enough. Patch applied. Thanks.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Where humor is concerned there are no standards -- no one can say
what is good or bad, although you can be sure that everyone will.
- John Kenneth Galbraith
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.