* Re: Trac+Git: rev-list with pathspec performance?
From: Stephen Bash @ 2010-10-07 17:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List
In-Reply-To: <17750617.441668.1286378804923.JavaMail.root@mail.hq.genarts.com>
> > Note that there is proof of concept
> > "tree blame" (in Perl) which generates such 'last change to file'
> > information, I think faster than running 'git rev-list -1 <file>'
> > for
> > each file. Even better would be to encode used algorithm in C.
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/150063/focus=150183
>
> My early experiments with your script are good for speed, but for some
> reason I'm always getting the first commit for a file rather than the
> most recent. I'll do some experimenting to see if I can uncover the
> issue.
Following up, I had to add -r to the diff-tree command line when requesting a subdirectory to work around the problem (script always returned the first commit).
I'm curious if it's faster to get the SHA of the sub-tree and compare that before actually running diff-tree? And for that matter, just run diff-tree on the sub-tree that we care about rather than a recursive sub-tree on the root? These may be early optimizations, but they're ideas that occurred to me while debugging the code...
> > P.S. Alternate solution would be to simply get rid of SVN-inspired
> > view. Git tracks history of a *project* as a whole, not set of
> > histories for individual files (like CVS).
After a lot of experimentation, this is basically what we did. I modified the Trac templates to not list the last change SHA or log message in the directory view. After all my testing, I just don't think there's a fast way to get this information from Git. This blame-dir script is the fastest alternative I've tried (about 5x faster than rev-list'ing each file), but it's still ~30 seconds on my machine (which is faster than our web server), and IMHO that's too long to ask a user to wait for a page to load.
Thanks,
Stephen
^ permalink raw reply
* Re: Linux 2.6.36-rc7
From: Eric Paris @ 2010-10-07 17:49 UTC (permalink / raw)
To: Alan Cox
Cc: Tvrtko Ursulin, Linus Torvalds, Linux Kernel Mailing List, agruen
In-Reply-To: <20101007190741.2dc62626@lxorguk.ukuu.org.uk>
On Thu, 2010-10-07 at 19:07 +0100, Alan Cox wrote:
> > I see two possibilities off the top of my head:
> >
> > I could just slap an (unused) priority field onto the end of the
> > fanotify_init() syscall (assuming Linus doesn't murder me) so we can
> > build that support out with explicit priorities down the line, which I
> > think might be overkill, or
> >
> > The other option (without breaking ABI as it stands today) is to define
> > some set of the fanotify_init() flags to be a priority field, we've got
> > 32 bits and only use 2 of them so giving 4-8 bits of that as a priority
> > (next cycle) isn't an issue and can be easily backwards compatible.
>
> Except you've then got a magic release that works differently to every
> other release afterwards and which sods law says will get shipped by some
> big vendor. Both your proposals are "we got the API wrong,
Correct.
> lets have one
> kernel that is special", that isn't good in the bigger scheme of things
> and will have if kernel 2.6.blah then crap forced into bits of app/lib
> code forever.
Not sure I understand this logic completely. I see both of those
options as: we'd have a 2.6.36 kernel which don't have a priority
feature (and would reject apps that try to use it) and that feature
could be built into 2.6.37. Apps built against 2.6.36 kernels would
still work on 2.6.37 (with a priority of 0 since that's all they could
set in 2.6.36)
> Given two chunks of "oh dear" last minute stuff would it be safer to
> simply punt and just pull the syscall/prototype itself (leaving the rest)
> for the release. That can go into the first pass of the next kernel tree,
> and if it the fixes and priority bits all work out may well then be tiny
> enough for -stable.
The safest thing would probably be to punt the syscalls to 2.6.37.
Which is sad since I know a number of people are already working against
them, but maybe that proves it's the best approach?
-Eric
^ permalink raw reply
* Re: git push <branch-name>
From: Eric Raible @ 2010-10-07 17:41 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Sverre Rabbelier, Git Mailing List
In-Reply-To: <4CADA5E3.5060405@drmicha.warpmail.net>
On Thu, Oct 7, 2010 at 3:50 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
>
> Now, if I have a remote foo and a branch foo, what is
>
> git push foo
>
> supposed to do?
http://thread.gmane.org/gmane.comp.version-control.git/158235/focus=158254
^ permalink raw reply
* aranym bug, manifests as "ida_remove called for id=13" on recent kernels
From: Al Viro @ 2010-10-07 17:49 UTC (permalink / raw)
To: linux-m68k; +Cc: linux-kernel
I've spent quite a while hunting that crap down; reverting VFS fix
mentioned in original thread *does* get rid of the symptoms, but so does the
patch below.
What happens is this: if ->follow_link() (usually something like
stat("/proc/2/fd", ...) done by pidof(8)) return ERR_PTR(-....), we return
to __do_follow_link() and do the following:
*p = dentry->d_inode->i_op->follow_link(dentry, nd);
error = PTR_ERR(*p);
if (!IS_ERR(*p)) {
char *s = nd_get_link(nd);
error = 0;
if (s)
error = __vfs_follow_link(nd, s);
else if (nd->last_type == LAST_BIND) {
error = force_reval_path(&nd->path, nd);
if (error)
path_put(&nd->path);
}
}
return error;
We _should_ return non-zero value; IS_ERR(ERR_PTR(-n)) is 1 and
PTR_ERR(ERR_PTR(n)) is -n. What happens instead is that this thing
actually returns 0. And no, it's not a miscompile. Patch below
removes the symptoms of the bug, but only if both parts are present.
I.e. *not* doing "report = 1" in proc_pid_follow_link() gives us
visible breakage, despite the fact that report is initialized as
1 and nothing except proc_pid_follow_link() ever tries to assign
anything to it. Seeing that fs/namei.c and fs/proc/base.c are
compiled separately, we can exclude gcc problems.
The cheapest way to reproduce is to boot with init=/bin/sh, then
mount /proc and have stat("/proc/2/exe", &st) called; if stat()
returns 0, we are fscked. The critical part is between return
from proc_exe_link() (we'll leave it via if (!mm) return -ENOENT;)
to return from __do_follow_link() -> do_follow_link() -> link_path_walk().
If somebody familiar with aranym guts are up to debugging that, more
power to them. If I would've seen it on real hardware, I'd suspect
something weird going on with caches, but...
FWIW, it's observable on amd64 host; I haven't tried it on x86. Version
of aranym is 0.9.6beta2-1 (one in lenny). Have fun...
Patch [*NOT* for inclusion into mainline, obviously] follows:
diff --git a/fs/namei.c b/fs/namei.c
index 24896e8..da5bb7f 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -524,6 +524,8 @@ static inline void path_to_nameidata(struct path *path, struct nameidata *nd)
nd->path.dentry = path->dentry;
}
+int report = 1;
+
static __always_inline int
__do_follow_link(struct path *path, struct nameidata *nd, void **p)
{
@@ -552,6 +554,8 @@ __do_follow_link(struct path *path, struct nameidata *nd, void **p)
path_put(&nd->path);
}
}
+ if (report && !error && IS_ERR(*p))
+ printk("fucked: %d %p\n", error, *p);
return error;
}
diff --git a/fs/proc/base.c b/fs/proc/base.c
index a1c43e7..24579de 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1513,6 +1513,7 @@ static void *proc_pid_follow_link(struct dentry *dentry, struct nameidata *nd)
goto out;
error = PROC_I(inode)->op.proc_get_link(inode, &nd->path);
+ {extern int report; report = 1;}
out:
return ERR_PTR(error);
}
^ permalink raw reply related
* Re: [PATCH v6 08/12] Handle async PF in a guest.
From: Rik van Riel @ 2010-10-07 17:48 UTC (permalink / raw)
To: Avi Kivity
Cc: Gleb Natapov, kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra,
tglx, hpa, cl, mtosatti
In-Reply-To: <4CAE00CB.1070400@redhat.com>
On 10/07/2010 01:18 PM, Avi Kivity wrote:
> On 10/07/2010 07:14 PM, Gleb Natapov wrote:
>> Host side keeps track of outstanding apfs and will not send apf for the
>> same phys address twice. It will halt vcpu instead.
>
> What about different pages, running the scheduler code?
>
> Oh, and we'll run the scheduler recursively.
When preempt is disabled in the guest, it will not invoke
the "reschedule for apf" code, but it will simply turn
into a normal page fault.
Last I looked, the scheduler code disabled preempt (for
obvious reasons).
--
All rights reversed
^ permalink raw reply
* Re: [PATCH v6 02/12] Halt vcpu if page it tries to access is swapped out.
From: Gleb Natapov @ 2010-10-07 17:48 UTC (permalink / raw)
To: Avi Kivity
Cc: Marcelo Tosatti, kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra,
tglx, hpa, riel, cl
In-Reply-To: <4CAD98CE.7020502@redhat.com>
On Thu, Oct 07, 2010 at 11:54:22AM +0200, Avi Kivity wrote:
> On 10/06/2010 12:52 PM, Gleb Natapov wrote:
> >On Wed, Oct 06, 2010 at 12:50:01PM +0200, Avi Kivity wrote:
> >> On 10/05/2010 04:59 PM, Marcelo Tosatti wrote:
> >> >On Mon, Oct 04, 2010 at 05:56:24PM +0200, Gleb Natapov wrote:
> >> >> If a guest accesses swapped out memory do not swap it in from vcpu thread
> >> >> context. Schedule work to do swapping and put vcpu into halted state
> >> >> instead.
> >> >>
> >> >> Interrupts will still be delivered to the guest and if interrupt will
> >> >> cause reschedule guest will continue to run another task.
> >> >>
> >> >> Signed-off-by: Gleb Natapov<gleb@redhat.com>
> >> >> ---
> >> >> arch/x86/include/asm/kvm_host.h | 17 +++
> >> >> arch/x86/kvm/Kconfig | 1 +
> >> >> arch/x86/kvm/Makefile | 1 +
> >> >> arch/x86/kvm/mmu.c | 51 +++++++++-
> >> >> arch/x86/kvm/paging_tmpl.h | 4 +-
> >> >> arch/x86/kvm/x86.c | 109 +++++++++++++++++++-
> >> >> include/linux/kvm_host.h | 31 ++++++
> >> >> include/trace/events/kvm.h | 88 ++++++++++++++++
> >> >> virt/kvm/Kconfig | 3 +
> >> >> virt/kvm/async_pf.c | 220 +++++++++++++++++++++++++++++++++++++++
> >> >> virt/kvm/async_pf.h | 36 +++++++
> >> >> virt/kvm/kvm_main.c | 57 ++++++++--
> >> >> 12 files changed, 603 insertions(+), 15 deletions(-)
> >> >> create mode 100644 virt/kvm/async_pf.c
> >> >> create mode 100644 virt/kvm/async_pf.h
> >> >>
> >> >
> >> >> + async_pf_cache = NULL;
> >> >> +}
> >> >> +
> >> >> +void kvm_async_pf_vcpu_init(struct kvm_vcpu *vcpu)
> >> >> +{
> >> >> + INIT_LIST_HEAD(&vcpu->async_pf.done);
> >> >> + INIT_LIST_HEAD(&vcpu->async_pf.queue);
> >> >> + spin_lock_init(&vcpu->async_pf.lock);
> >> >> +}
> >> >> +
> >> >> +static void async_pf_execute(struct work_struct *work)
> >> >> +{
> >> >> + struct page *page;
> >> >> + struct kvm_async_pf *apf =
> >> >> + container_of(work, struct kvm_async_pf, work);
> >> >> + struct mm_struct *mm = apf->mm;
> >> >> + struct kvm_vcpu *vcpu = apf->vcpu;
> >> >> + unsigned long addr = apf->addr;
> >> >> + gva_t gva = apf->gva;
> >> >> +
> >> >> + might_sleep();
> >> >> +
> >> >> + use_mm(mm);
> >> >> + down_read(&mm->mmap_sem);
> >> >> + get_user_pages(current, mm, addr, 1, 1, 0,&page, NULL);
> >> >> + up_read(&mm->mmap_sem);
> >> >> + unuse_mm(mm);
> >> >> +
> >> >> + spin_lock(&vcpu->async_pf.lock);
> >> >> + list_add_tail(&apf->link,&vcpu->async_pf.done);
> >> >> + apf->page = page;
> >> >> + spin_unlock(&vcpu->async_pf.lock);
> >> >
> >> >This can fail, and apf->page become NULL.
> >>
> >> Does it even become NULL? On error, get_user_pages() won't update
> >> the pages argument, so page becomes garbage here.
> >>
> >apf is allocated with kmem_cache_zalloc() and ->page is set to NULL in
> >kvm_setup_async_pf() to be extra sure.
> >
>
> But you assign apf->page = page;, overriding it with garbage here.
>
Ah, right you are.
--
Gleb.
^ permalink raw reply
* Re: [PATCH v6 08/12] Handle async PF in a guest.
From: Rik van Riel @ 2010-10-07 17:48 UTC (permalink / raw)
To: Avi Kivity
Cc: Gleb Natapov, kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra,
tglx, hpa, cl, mtosatti
In-Reply-To: <4CAE00CB.1070400@redhat.com>
On 10/07/2010 01:18 PM, Avi Kivity wrote:
> On 10/07/2010 07:14 PM, Gleb Natapov wrote:
>> Host side keeps track of outstanding apfs and will not send apf for the
>> same phys address twice. It will halt vcpu instead.
>
> What about different pages, running the scheduler code?
>
> Oh, and we'll run the scheduler recursively.
When preempt is disabled in the guest, it will not invoke
the "reschedule for apf" code, but it will simply turn
into a normal page fault.
Last I looked, the scheduler code disabled preempt (for
obvious reasons).
--
All rights reversed
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v6 02/12] Halt vcpu if page it tries to access is swapped out.
From: Gleb Natapov @ 2010-10-07 17:48 UTC (permalink / raw)
To: Avi Kivity
Cc: Marcelo Tosatti, kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra,
tglx, hpa, riel, cl
In-Reply-To: <4CAD98CE.7020502@redhat.com>
On Thu, Oct 07, 2010 at 11:54:22AM +0200, Avi Kivity wrote:
> On 10/06/2010 12:52 PM, Gleb Natapov wrote:
> >On Wed, Oct 06, 2010 at 12:50:01PM +0200, Avi Kivity wrote:
> >> On 10/05/2010 04:59 PM, Marcelo Tosatti wrote:
> >> >On Mon, Oct 04, 2010 at 05:56:24PM +0200, Gleb Natapov wrote:
> >> >> If a guest accesses swapped out memory do not swap it in from vcpu thread
> >> >> context. Schedule work to do swapping and put vcpu into halted state
> >> >> instead.
> >> >>
> >> >> Interrupts will still be delivered to the guest and if interrupt will
> >> >> cause reschedule guest will continue to run another task.
> >> >>
> >> >> Signed-off-by: Gleb Natapov<gleb@redhat.com>
> >> >> ---
> >> >> arch/x86/include/asm/kvm_host.h | 17 +++
> >> >> arch/x86/kvm/Kconfig | 1 +
> >> >> arch/x86/kvm/Makefile | 1 +
> >> >> arch/x86/kvm/mmu.c | 51 +++++++++-
> >> >> arch/x86/kvm/paging_tmpl.h | 4 +-
> >> >> arch/x86/kvm/x86.c | 109 +++++++++++++++++++-
> >> >> include/linux/kvm_host.h | 31 ++++++
> >> >> include/trace/events/kvm.h | 88 ++++++++++++++++
> >> >> virt/kvm/Kconfig | 3 +
> >> >> virt/kvm/async_pf.c | 220 +++++++++++++++++++++++++++++++++++++++
> >> >> virt/kvm/async_pf.h | 36 +++++++
> >> >> virt/kvm/kvm_main.c | 57 ++++++++--
> >> >> 12 files changed, 603 insertions(+), 15 deletions(-)
> >> >> create mode 100644 virt/kvm/async_pf.c
> >> >> create mode 100644 virt/kvm/async_pf.h
> >> >>
> >> >
> >> >> + async_pf_cache = NULL;
> >> >> +}
> >> >> +
> >> >> +void kvm_async_pf_vcpu_init(struct kvm_vcpu *vcpu)
> >> >> +{
> >> >> + INIT_LIST_HEAD(&vcpu->async_pf.done);
> >> >> + INIT_LIST_HEAD(&vcpu->async_pf.queue);
> >> >> + spin_lock_init(&vcpu->async_pf.lock);
> >> >> +}
> >> >> +
> >> >> +static void async_pf_execute(struct work_struct *work)
> >> >> +{
> >> >> + struct page *page;
> >> >> + struct kvm_async_pf *apf =
> >> >> + container_of(work, struct kvm_async_pf, work);
> >> >> + struct mm_struct *mm = apf->mm;
> >> >> + struct kvm_vcpu *vcpu = apf->vcpu;
> >> >> + unsigned long addr = apf->addr;
> >> >> + gva_t gva = apf->gva;
> >> >> +
> >> >> + might_sleep();
> >> >> +
> >> >> + use_mm(mm);
> >> >> + down_read(&mm->mmap_sem);
> >> >> + get_user_pages(current, mm, addr, 1, 1, 0,&page, NULL);
> >> >> + up_read(&mm->mmap_sem);
> >> >> + unuse_mm(mm);
> >> >> +
> >> >> + spin_lock(&vcpu->async_pf.lock);
> >> >> + list_add_tail(&apf->link,&vcpu->async_pf.done);
> >> >> + apf->page = page;
> >> >> + spin_unlock(&vcpu->async_pf.lock);
> >> >
> >> >This can fail, and apf->page become NULL.
> >>
> >> Does it even become NULL? On error, get_user_pages() won't update
> >> the pages argument, so page becomes garbage here.
> >>
> >apf is allocated with kmem_cache_zalloc() and ->page is set to NULL in
> >kvm_setup_async_pf() to be extra sure.
> >
>
> But you assign apf->page = page;, overriding it with garbage here.
>
Ah, right you are.
--
Gleb.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v6 02/12] Halt vcpu if page it tries to access is swapped out.
From: Gleb Natapov @ 2010-10-07 17:47 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra, tglx, hpa, riel,
cl, mtosatti
In-Reply-To: <4CAD97D0.70100@redhat.com>
On Thu, Oct 07, 2010 at 11:50:08AM +0200, Avi Kivity wrote:
> On 10/04/2010 05:56 PM, Gleb Natapov wrote:
> >If a guest accesses swapped out memory do not swap it in from vcpu thread
> >context. Schedule work to do swapping and put vcpu into halted state
> >instead.
> >
> >Interrupts will still be delivered to the guest and if interrupt will
> >cause reschedule guest will continue to run another task.
> >
> >
> >+
> >+static bool can_do_async_pf(struct kvm_vcpu *vcpu)
> >+{
> >+ if (unlikely(!irqchip_in_kernel(vcpu->kvm) ||
> >+ kvm_event_needs_reinjection(vcpu)))
> >+ return false;
> >+
> >+ return kvm_x86_ops->interrupt_allowed(vcpu);
> >+}
>
> Strictly speaking, if the cpu can handle NMIs it can take an apf?
>
We can always do apf, but if vcpu can't do anything hwy bother. For NMI
watchdog yes, may be it is worth to allow apf if nmi is allowed.
> >@@ -5112,6 +5122,13 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> > if (unlikely(r))
> > goto out;
> >
> >+ kvm_check_async_pf_completion(vcpu);
> >+ if (vcpu->arch.mp_state == KVM_MP_STATE_HALTED) {
> >+ /* Page is swapped out. Do synthetic halt */
> >+ r = 1;
> >+ goto out;
> >+ }
> >+
>
> Why do it here in the fast path? Can't you halt the cpu when
> starting the page fault?
Page fault may complete before guest re-entry. We do not want to halt vcpu
in this case.
>
> I guess the apf threads can't touch mp_state, but they can have a
> KVM_REQ to trigger the check.
This will require KVM_REQ check on fast path, so what's the difference
performance wise.
>
> > if (kvm_check_request(KVM_REQ_EVENT, vcpu) || req_int_win) {
> > inject_pending_event(vcpu);
> >
> >@@ -5781,6 +5798,9 @@ int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu)
> >
> > kvm_make_request(KVM_REQ_EVENT, vcpu);
> >
> >+ kvm_clear_async_pf_completion_queue(vcpu);
> >+ memset(vcpu->arch.apf.gfns, 0xff, sizeof vcpu->arch.apf.gfns);
>
> An ordinary for loop is less tricky, even if it means one more line.
>
> >
> >@@ -6040,6 +6064,7 @@ void kvm_arch_flush_shadow(struct kvm *kvm)
> > int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
> > {
> > return vcpu->arch.mp_state == KVM_MP_STATE_RUNNABLE
> >+ || !list_empty_careful(&vcpu->async_pf.done)
> > || vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
> > || vcpu->arch.nmi_pending ||
> > (kvm_arch_interrupt_allowed(vcpu)&&
>
> Unrelated, shouldn't kvm_arch_vcpu_runnable() look at
> vcpu->requests? Specifically KVM_REQ_EVENT?
I think KVM_REQ_EVENT is covered by checking nmi and interrupt queue
here.
>
> >+static void kvm_add_async_pf_gfn(struct kvm_vcpu *vcpu, gfn_t gfn)
> >+{
> >+ u32 key = kvm_async_pf_hash_fn(gfn);
> >+
> >+ while (vcpu->arch.apf.gfns[key] != -1)
> >+ key = kvm_async_pf_next_probe(key);
>
> Not sure what that -1 converts to on i386 where gfn_t is u64.
Will check.
> >+
> >+void kvm_arch_async_page_not_present(struct kvm_vcpu *vcpu,
> >+ struct kvm_async_pf *work)
> >+{
> >+ vcpu->arch.mp_state = KVM_MP_STATE_HALTED;
> >+
> >+ if (work == kvm_double_apf)
> >+ trace_kvm_async_pf_doublefault(kvm_rip_read(vcpu));
> >+ else {
> >+ trace_kvm_async_pf_not_present(work->gva);
> >+
> >+ kvm_add_async_pf_gfn(vcpu, work->arch.gfn);
> >+ }
> >+}
>
> Just have vcpu as the argument for tracepoints to avoid
> unconditional kvm_rip_read (slow on Intel), and call kvm_rip_read()
> in tp_fast_assign(). Similarly you can pass work instead of
> work->gva, though that's not nearly as important.
>
Will do.
> >+
> >+TRACE_EVENT(
> >+ kvm_async_pf_not_present,
> >+ TP_PROTO(u64 gva),
> >+ TP_ARGS(gva),
>
> Do you actually have a gva with tdp? With nested virtualization,
> how do you interpret this gva?
With tdp it is gpa just like tdp_page_fault gets gpa where shadow page
version gets gva. Nested virtualization is too complex to interpret.
> >+
> >+TRACE_EVENT(
> >+ kvm_async_pf_completed,
> >+ TP_PROTO(unsigned long address, struct page *page, u64 gva),
> >+ TP_ARGS(address, page, gva),
>
> What does address mean? There's also gva?
>
hva.
> >+
> >+ TP_STRUCT__entry(
> >+ __field(unsigned long, address)
> >+ __field(struct page*, page)
> >+ __field(u64, gva)
> >+ ),
> >+
> >+ TP_fast_assign(
> >+ __entry->address = address;
> >+ __entry->page = page;
> >+ __entry->gva = gva;
> >+ ),
>
> Recording a struct page * in a tracepoint? Userspace can read this
> entry, better to the page_to_pfn() here.
>
OK.
>
> >+void kvm_clear_async_pf_completion_queue(struct kvm_vcpu *vcpu)
> >+{
> >+ /* cancel outstanding work queue item */
> >+ while (!list_empty(&vcpu->async_pf.queue)) {
> >+ struct kvm_async_pf *work =
> >+ list_entry(vcpu->async_pf.queue.next,
> >+ typeof(*work), queue);
> >+ cancel_work_sync(&work->work);
> >+ list_del(&work->queue);
> >+ if (!work->page) /* work was canceled */
> >+ kmem_cache_free(async_pf_cache, work);
> >+ }
>
> Are you holding any lock here?
>
> If not, what protects vcpu->async_pf.queue?
Nothing. It is accessed only from vcpu thread.
> If yes, cancel_work_sync() will need to aquire it too (in case work
> is running now and needs to take the lock, and cacncel_work_sync()
> needs to wait for it) -> deadlock.
>
Work never touches this list.
> >+
> >+ /* do alloc nowait since if we are going to sleep anyway we
> >+ may as well sleep faulting in page */
> /*
> * multi
> * line
> * comment
> */
>
> (but a good one, this is subtle)
>
> I missed where you halt the vcpu. Can you point me at the function?
>
> Note this is a synthetic halt and must not be visible to live
> migration, or we risk live migrating a halted state which doesn't
> really exist.
>
> Might be simplest to drain the apf queue on any of the save/restore ioctls.
>
So that "info cpu" will interfere with apf? Migration should work
in regular way. apf state should not be migrated since it has no meaning
on the destination. I'll make sure synthetic halt state will not
interfere with migration.
--
Gleb.
^ permalink raw reply
* Re: [PATCH v6 02/12] Halt vcpu if page it tries to access is swapped out.
From: Gleb Natapov @ 2010-10-07 17:47 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra, tglx, hpa, riel,
cl, mtosatti
In-Reply-To: <4CAD97D0.70100@redhat.com>
On Thu, Oct 07, 2010 at 11:50:08AM +0200, Avi Kivity wrote:
> On 10/04/2010 05:56 PM, Gleb Natapov wrote:
> >If a guest accesses swapped out memory do not swap it in from vcpu thread
> >context. Schedule work to do swapping and put vcpu into halted state
> >instead.
> >
> >Interrupts will still be delivered to the guest and if interrupt will
> >cause reschedule guest will continue to run another task.
> >
> >
> >+
> >+static bool can_do_async_pf(struct kvm_vcpu *vcpu)
> >+{
> >+ if (unlikely(!irqchip_in_kernel(vcpu->kvm) ||
> >+ kvm_event_needs_reinjection(vcpu)))
> >+ return false;
> >+
> >+ return kvm_x86_ops->interrupt_allowed(vcpu);
> >+}
>
> Strictly speaking, if the cpu can handle NMIs it can take an apf?
>
We can always do apf, but if vcpu can't do anything hwy bother. For NMI
watchdog yes, may be it is worth to allow apf if nmi is allowed.
> >@@ -5112,6 +5122,13 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> > if (unlikely(r))
> > goto out;
> >
> >+ kvm_check_async_pf_completion(vcpu);
> >+ if (vcpu->arch.mp_state == KVM_MP_STATE_HALTED) {
> >+ /* Page is swapped out. Do synthetic halt */
> >+ r = 1;
> >+ goto out;
> >+ }
> >+
>
> Why do it here in the fast path? Can't you halt the cpu when
> starting the page fault?
Page fault may complete before guest re-entry. We do not want to halt vcpu
in this case.
>
> I guess the apf threads can't touch mp_state, but they can have a
> KVM_REQ to trigger the check.
This will require KVM_REQ check on fast path, so what's the difference
performance wise.
>
> > if (kvm_check_request(KVM_REQ_EVENT, vcpu) || req_int_win) {
> > inject_pending_event(vcpu);
> >
> >@@ -5781,6 +5798,9 @@ int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu)
> >
> > kvm_make_request(KVM_REQ_EVENT, vcpu);
> >
> >+ kvm_clear_async_pf_completion_queue(vcpu);
> >+ memset(vcpu->arch.apf.gfns, 0xff, sizeof vcpu->arch.apf.gfns);
>
> An ordinary for loop is less tricky, even if it means one more line.
>
> >
> >@@ -6040,6 +6064,7 @@ void kvm_arch_flush_shadow(struct kvm *kvm)
> > int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
> > {
> > return vcpu->arch.mp_state == KVM_MP_STATE_RUNNABLE
> >+ || !list_empty_careful(&vcpu->async_pf.done)
> > || vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
> > || vcpu->arch.nmi_pending ||
> > (kvm_arch_interrupt_allowed(vcpu)&&
>
> Unrelated, shouldn't kvm_arch_vcpu_runnable() look at
> vcpu->requests? Specifically KVM_REQ_EVENT?
I think KVM_REQ_EVENT is covered by checking nmi and interrupt queue
here.
>
> >+static void kvm_add_async_pf_gfn(struct kvm_vcpu *vcpu, gfn_t gfn)
> >+{
> >+ u32 key = kvm_async_pf_hash_fn(gfn);
> >+
> >+ while (vcpu->arch.apf.gfns[key] != -1)
> >+ key = kvm_async_pf_next_probe(key);
>
> Not sure what that -1 converts to on i386 where gfn_t is u64.
Will check.
> >+
> >+void kvm_arch_async_page_not_present(struct kvm_vcpu *vcpu,
> >+ struct kvm_async_pf *work)
> >+{
> >+ vcpu->arch.mp_state = KVM_MP_STATE_HALTED;
> >+
> >+ if (work == kvm_double_apf)
> >+ trace_kvm_async_pf_doublefault(kvm_rip_read(vcpu));
> >+ else {
> >+ trace_kvm_async_pf_not_present(work->gva);
> >+
> >+ kvm_add_async_pf_gfn(vcpu, work->arch.gfn);
> >+ }
> >+}
>
> Just have vcpu as the argument for tracepoints to avoid
> unconditional kvm_rip_read (slow on Intel), and call kvm_rip_read()
> in tp_fast_assign(). Similarly you can pass work instead of
> work->gva, though that's not nearly as important.
>
Will do.
> >+
> >+TRACE_EVENT(
> >+ kvm_async_pf_not_present,
> >+ TP_PROTO(u64 gva),
> >+ TP_ARGS(gva),
>
> Do you actually have a gva with tdp? With nested virtualization,
> how do you interpret this gva?
With tdp it is gpa just like tdp_page_fault gets gpa where shadow page
version gets gva. Nested virtualization is too complex to interpret.
> >+
> >+TRACE_EVENT(
> >+ kvm_async_pf_completed,
> >+ TP_PROTO(unsigned long address, struct page *page, u64 gva),
> >+ TP_ARGS(address, page, gva),
>
> What does address mean? There's also gva?
>
hva.
> >+
> >+ TP_STRUCT__entry(
> >+ __field(unsigned long, address)
> >+ __field(struct page*, page)
> >+ __field(u64, gva)
> >+ ),
> >+
> >+ TP_fast_assign(
> >+ __entry->address = address;
> >+ __entry->page = page;
> >+ __entry->gva = gva;
> >+ ),
>
> Recording a struct page * in a tracepoint? Userspace can read this
> entry, better to the page_to_pfn() here.
>
OK.
>
> >+void kvm_clear_async_pf_completion_queue(struct kvm_vcpu *vcpu)
> >+{
> >+ /* cancel outstanding work queue item */
> >+ while (!list_empty(&vcpu->async_pf.queue)) {
> >+ struct kvm_async_pf *work =
> >+ list_entry(vcpu->async_pf.queue.next,
> >+ typeof(*work), queue);
> >+ cancel_work_sync(&work->work);
> >+ list_del(&work->queue);
> >+ if (!work->page) /* work was canceled */
> >+ kmem_cache_free(async_pf_cache, work);
> >+ }
>
> Are you holding any lock here?
>
> If not, what protects vcpu->async_pf.queue?
Nothing. It is accessed only from vcpu thread.
> If yes, cancel_work_sync() will need to aquire it too (in case work
> is running now and needs to take the lock, and cacncel_work_sync()
> needs to wait for it) -> deadlock.
>
Work never touches this list.
> >+
> >+ /* do alloc nowait since if we are going to sleep anyway we
> >+ may as well sleep faulting in page */
> /*
> * multi
> * line
> * comment
> */
>
> (but a good one, this is subtle)
>
> I missed where you halt the vcpu. Can you point me at the function?
>
> Note this is a synthetic halt and must not be visible to live
> migration, or we risk live migrating a halted state which doesn't
> really exist.
>
> Might be simplest to drain the apf queue on any of the save/restore ioctls.
>
So that "info cpu" will interfere with apf? Migration should work
in regular way. apf state should not be migrated since it has no meaning
on the destination. I'll make sure synthetic halt state will not
interfere with migration.
--
Gleb.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 08/10] memcg: add cgroupfs interface to memcg dirty limits
From: Greg Thelen @ 2010-10-07 17:46 UTC (permalink / raw)
To: Ciju Rajan K
Cc: Andrew Morton, linux-kernel, linux-mm, containers, Andrea Righi,
Balbir Singh, KAMEZAWA Hiroyuki, Daisuke Nishimura
In-Reply-To: <4CAD6774.7030302@linux.vnet.ibm.com>
Ciju Rajan K <ciju@linux.vnet.ibm.com> writes:
> Greg Thelen wrote:
>> Add cgroupfs interface to memcg dirty page limits:
>> Direct write-out is controlled with:
>> - memory.dirty_ratio
>> - memory.dirty_bytes
>>
>> Background write-out is controlled with:
>> - memory.dirty_background_ratio
>> - memory.dirty_background_bytes
>>
>> Signed-off-by: Andrea Righi <arighi@develer.com>
>> Signed-off-by: Greg Thelen <gthelen@google.com>
>> ---
>> mm/memcontrol.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 89 insertions(+), 0 deletions(-)
>>
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index 6ec2625..2d45a0a 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -100,6 +100,13 @@ enum mem_cgroup_stat_index {
>> MEM_CGROUP_STAT_NSTATS,
>> };
>>
>> +enum {
>> + MEM_CGROUP_DIRTY_RATIO,
>> + MEM_CGROUP_DIRTY_BYTES,
>> + MEM_CGROUP_DIRTY_BACKGROUND_RATIO,
>> + MEM_CGROUP_DIRTY_BACKGROUND_BYTES,
>> +};
>> +
>> struct mem_cgroup_stat_cpu {
>> s64 count[MEM_CGROUP_STAT_NSTATS];
>> };
>> @@ -4292,6 +4299,64 @@ static int mem_cgroup_oom_control_write(struct cgroup *cgrp,
>> return 0;
>> }
>>
>> +static u64 mem_cgroup_dirty_read(struct cgroup *cgrp, struct cftype *cft)
>> +{
>> + struct mem_cgroup *mem = mem_cgroup_from_cont(cgrp);
>> + bool root;
>> +
>> + root = mem_cgroup_is_root(mem);
>> +
>> + switch (cft->private) {
>> + case MEM_CGROUP_DIRTY_RATIO:
>> + return root ? vm_dirty_ratio : mem->dirty_param.dirty_ratio;
>> + case MEM_CGROUP_DIRTY_BYTES:
>> + return root ? vm_dirty_bytes : mem->dirty_param.dirty_bytes;
>> + case MEM_CGROUP_DIRTY_BACKGROUND_RATIO:
>> + return root ? dirty_background_ratio :
>> + mem->dirty_param.dirty_background_ratio;
>> + case MEM_CGROUP_DIRTY_BACKGROUND_BYTES:
>> + return root ? dirty_background_bytes :
>> + mem->dirty_param.dirty_background_bytes;
>> + default:
>> + BUG();
>> + }
>> +}
>> +
>> +static int
>> +mem_cgroup_dirty_write(struct cgroup *cgrp, struct cftype *cft, u64 val)
>> +{
>> + struct mem_cgroup *memcg = mem_cgroup_from_cont(cgrp);
>> + int type = cft->private;
>> +
>> + if (cgrp->parent == NULL)
>> + return -EINVAL;
>> + if ((type == MEM_CGROUP_DIRTY_RATIO ||
>> + type == MEM_CGROUP_DIRTY_BACKGROUND_RATIO) && val > 100)
>> + return -EINVAL;
>> + switch (type) {
>> + case MEM_CGROUP_DIRTY_RATIO:
>> + memcg->dirty_param.dirty_ratio = val;
>> + memcg->dirty_param.dirty_bytes = 0;
>> + break;
>> + case MEM_CGROUP_DIRTY_BYTES:
>> + memcg->dirty_param.dirty_bytes = val;
>> + memcg->dirty_param.dirty_ratio = 0;
>> + break;
>> + case MEM_CGROUP_DIRTY_BACKGROUND_RATIO:
>> + memcg->dirty_param.dirty_background_ratio = val;
>> + memcg->dirty_param.dirty_background_bytes = 0;
>> + break;
>> + case MEM_CGROUP_DIRTY_BACKGROUND_BYTES:
>> + memcg->dirty_param.dirty_background_bytes = val;
>> + memcg->dirty_param.dirty_background_ratio = 0;
>> + break;
>> + default:
>> + BUG();
>> + break;
>> + }
>> + return 0;
>> +}
>> +
>> static struct cftype mem_cgroup_files[] = {
>> {
>> .name = "usage_in_bytes",
>> @@ -4355,6 +4420,30 @@ static struct cftype mem_cgroup_files[] = {
>> .unregister_event = mem_cgroup_oom_unregister_event,
>> .private = MEMFILE_PRIVATE(_OOM_TYPE, OOM_CONTROL),
>> },
>> + {
>> + .name = "dirty_ratio",
>> + .read_u64 = mem_cgroup_dirty_read,
>> + .write_u64 = mem_cgroup_dirty_write,
>> + .private = MEM_CGROUP_DIRTY_RATIO,
>> + },
>> + {
>> + .name = "dirty_bytes",
>> + .read_u64 = mem_cgroup_dirty_read,
>> + .write_u64 = mem_cgroup_dirty_write,
>> + .private = MEM_CGROUP_DIRTY_BYTES,
>> + },
>> + {
>>
> Is it a good idea to rename "dirty_bytes" to "dirty_limit_in_bytes" ?
> So that it can match with other memcg tunable naming convention.
> We already have memory.memsw.limit_in_bytes, memory.limit_in_bytes,
> memory.soft_limit_in_bytes, etc.
I see your point in trying to be more internally consistent with other
memcg counter.
It's a trade-off, either use names consistent with /proc/sys/vm, or use
names similar to other memory.* control files. I prefer your suggestion
and will rename as you suggested, unless I hear strong objection.
>> + .name = "dirty_background_ratio",
>> + .read_u64 = mem_cgroup_dirty_read,
>> + .write_u64 = mem_cgroup_dirty_write,
>> + .private = MEM_CGROUP_DIRTY_BACKGROUND_RATIO,
>> + },
>> + {
>> + .name = "dirty_background_bytes",
>> + .read_u64 = mem_cgroup_dirty_read,
>> + .write_u64 = mem_cgroup_dirty_write,
>> + .private = MEM_CGROUP_DIRTY_BACKGROUND_BYTES,
>>
> Similarly "dirty_background_bytes" to dirty_background_limit_in_bytes ?
>> + },
>> };
>>
>> #ifdef CONFIG_CGROUP_MEM_RES_CTLR_SWAP
>>
PS: I am collecting performance data on patch series (including Kame's
lockless writeback stats). I should have some useful data today.
^ permalink raw reply
* Re: [PATCH 08/10] memcg: add cgroupfs interface to memcg dirty limits
From: Greg Thelen @ 2010-10-07 17:46 UTC (permalink / raw)
To: Ciju Rajan K
Cc: Andrew Morton, linux-kernel, linux-mm, containers, Andrea Righi,
Balbir Singh, KAMEZAWA Hiroyuki, Daisuke Nishimura
In-Reply-To: <4CAD6774.7030302@linux.vnet.ibm.com>
Ciju Rajan K <ciju@linux.vnet.ibm.com> writes:
> Greg Thelen wrote:
>> Add cgroupfs interface to memcg dirty page limits:
>> Direct write-out is controlled with:
>> - memory.dirty_ratio
>> - memory.dirty_bytes
>>
>> Background write-out is controlled with:
>> - memory.dirty_background_ratio
>> - memory.dirty_background_bytes
>>
>> Signed-off-by: Andrea Righi <arighi@develer.com>
>> Signed-off-by: Greg Thelen <gthelen@google.com>
>> ---
>> mm/memcontrol.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 89 insertions(+), 0 deletions(-)
>>
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index 6ec2625..2d45a0a 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -100,6 +100,13 @@ enum mem_cgroup_stat_index {
>> MEM_CGROUP_STAT_NSTATS,
>> };
>>
>> +enum {
>> + MEM_CGROUP_DIRTY_RATIO,
>> + MEM_CGROUP_DIRTY_BYTES,
>> + MEM_CGROUP_DIRTY_BACKGROUND_RATIO,
>> + MEM_CGROUP_DIRTY_BACKGROUND_BYTES,
>> +};
>> +
>> struct mem_cgroup_stat_cpu {
>> s64 count[MEM_CGROUP_STAT_NSTATS];
>> };
>> @@ -4292,6 +4299,64 @@ static int mem_cgroup_oom_control_write(struct cgroup *cgrp,
>> return 0;
>> }
>>
>> +static u64 mem_cgroup_dirty_read(struct cgroup *cgrp, struct cftype *cft)
>> +{
>> + struct mem_cgroup *mem = mem_cgroup_from_cont(cgrp);
>> + bool root;
>> +
>> + root = mem_cgroup_is_root(mem);
>> +
>> + switch (cft->private) {
>> + case MEM_CGROUP_DIRTY_RATIO:
>> + return root ? vm_dirty_ratio : mem->dirty_param.dirty_ratio;
>> + case MEM_CGROUP_DIRTY_BYTES:
>> + return root ? vm_dirty_bytes : mem->dirty_param.dirty_bytes;
>> + case MEM_CGROUP_DIRTY_BACKGROUND_RATIO:
>> + return root ? dirty_background_ratio :
>> + mem->dirty_param.dirty_background_ratio;
>> + case MEM_CGROUP_DIRTY_BACKGROUND_BYTES:
>> + return root ? dirty_background_bytes :
>> + mem->dirty_param.dirty_background_bytes;
>> + default:
>> + BUG();
>> + }
>> +}
>> +
>> +static int
>> +mem_cgroup_dirty_write(struct cgroup *cgrp, struct cftype *cft, u64 val)
>> +{
>> + struct mem_cgroup *memcg = mem_cgroup_from_cont(cgrp);
>> + int type = cft->private;
>> +
>> + if (cgrp->parent == NULL)
>> + return -EINVAL;
>> + if ((type == MEM_CGROUP_DIRTY_RATIO ||
>> + type == MEM_CGROUP_DIRTY_BACKGROUND_RATIO) && val > 100)
>> + return -EINVAL;
>> + switch (type) {
>> + case MEM_CGROUP_DIRTY_RATIO:
>> + memcg->dirty_param.dirty_ratio = val;
>> + memcg->dirty_param.dirty_bytes = 0;
>> + break;
>> + case MEM_CGROUP_DIRTY_BYTES:
>> + memcg->dirty_param.dirty_bytes = val;
>> + memcg->dirty_param.dirty_ratio = 0;
>> + break;
>> + case MEM_CGROUP_DIRTY_BACKGROUND_RATIO:
>> + memcg->dirty_param.dirty_background_ratio = val;
>> + memcg->dirty_param.dirty_background_bytes = 0;
>> + break;
>> + case MEM_CGROUP_DIRTY_BACKGROUND_BYTES:
>> + memcg->dirty_param.dirty_background_bytes = val;
>> + memcg->dirty_param.dirty_background_ratio = 0;
>> + break;
>> + default:
>> + BUG();
>> + break;
>> + }
>> + return 0;
>> +}
>> +
>> static struct cftype mem_cgroup_files[] = {
>> {
>> .name = "usage_in_bytes",
>> @@ -4355,6 +4420,30 @@ static struct cftype mem_cgroup_files[] = {
>> .unregister_event = mem_cgroup_oom_unregister_event,
>> .private = MEMFILE_PRIVATE(_OOM_TYPE, OOM_CONTROL),
>> },
>> + {
>> + .name = "dirty_ratio",
>> + .read_u64 = mem_cgroup_dirty_read,
>> + .write_u64 = mem_cgroup_dirty_write,
>> + .private = MEM_CGROUP_DIRTY_RATIO,
>> + },
>> + {
>> + .name = "dirty_bytes",
>> + .read_u64 = mem_cgroup_dirty_read,
>> + .write_u64 = mem_cgroup_dirty_write,
>> + .private = MEM_CGROUP_DIRTY_BYTES,
>> + },
>> + {
>>
> Is it a good idea to rename "dirty_bytes" to "dirty_limit_in_bytes" ?
> So that it can match with other memcg tunable naming convention.
> We already have memory.memsw.limit_in_bytes, memory.limit_in_bytes,
> memory.soft_limit_in_bytes, etc.
I see your point in trying to be more internally consistent with other
memcg counter.
It's a trade-off, either use names consistent with /proc/sys/vm, or use
names similar to other memory.* control files. I prefer your suggestion
and will rename as you suggested, unless I hear strong objection.
>> + .name = "dirty_background_ratio",
>> + .read_u64 = mem_cgroup_dirty_read,
>> + .write_u64 = mem_cgroup_dirty_write,
>> + .private = MEM_CGROUP_DIRTY_BACKGROUND_RATIO,
>> + },
>> + {
>> + .name = "dirty_background_bytes",
>> + .read_u64 = mem_cgroup_dirty_read,
>> + .write_u64 = mem_cgroup_dirty_write,
>> + .private = MEM_CGROUP_DIRTY_BACKGROUND_BYTES,
>>
> Similarly "dirty_background_bytes" to dirty_background_limit_in_bytes ?
>> + },
>> };
>>
>> #ifdef CONFIG_CGROUP_MEM_RES_CTLR_SWAP
>>
PS: I am collecting performance data on patch series (including Kame's
lockless writeback stats). I should have some useful data today.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [Bug 30684] r300g: OpenVG demos fail to render properly
From: bugzilla-daemon @ 2010-10-07 17:45 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-30684-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=30684
--- Comment #2 from Sergey Kondakov <virtuousfox@gmail.com> 2010-10-07 10:45:42 PDT ---
Created an attachment (id=39260)
--> (https://bugs.freedesktop.org/attachment.cgi?id=39260)
sp_x11.jpg
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [U-Boot] [PATCH v2 0/6] Add ARM flat device tree support
From: Wolfgang Denk @ 2010-10-07 17:45 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AANLkTi=pWR=UnByG0gGiqA4dK++5HA5XQCQo8Cfn9XUK@mail.gmail.com>
Dear John Rigby,
In message <AANLkTi=pWR=UnByG0gGiqA4dK++5HA5XQCQo8Cfn9XUK@mail.gmail.com> you wrote:
> There have been no NACK's to this and one Tested-by, so can this
> series go into 2010.12?
Sure. Sorry, I'm late with ARM related stuff, but your patches are on
my list.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"No one talks peace unless he's ready to back it up with war."
"He talks of peace if it is the only way to live."
-- Colonel Green and Surak of Vulcan, "The Savage Curtain",
stardate 5906.5.
^ permalink raw reply
* [Bug 30684] r300g: OpenVG demos fail to render properly
From: bugzilla-daemon @ 2010-10-07 17:45 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-30684-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=30684
--- Comment #1 from Sergey Kondakov <virtuousfox@gmail.com> 2010-10-07 10:45:18 PDT ---
Created an attachment (id=39259)
--> (https://bugs.freedesktop.org/attachment.cgi?id=39259)
lion_x11.jpg
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network interface
From: Narendra_K @ 2010-10-07 17:44 UTC (permalink / raw)
To: greg
Cc: kay.sievers, Matt_Domsch, netdev, linux-hotplug, linux-pci,
Jordan_Hargrave, Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007171532.GA29857@kroah.com>
On Thu, Oct 07, 2010 at 10:45:32PM +0530, Greg KH wrote:
> On Thu, Oct 07, 2010 at 07:05:14PM +0200, Kay Sievers wrote:
> > On Thu, Oct 7, 2010 at 18:48, Greg KH <greg@kroah.com> wrote:
> > > On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> > >> 1) SMBIOS type 41 method. Windows does not use this today, and I
> > >> can't speak to their future plans. Narendra's kernel patch does,
> > >> as has biosdevname, the udev helper we first wrote for this
> > >> purpose, for several years.
> > >
> > > Then stick with that udev helper please :)
> >
> > What about just exporting this information in sysfs, and not touch the
> naming?
>
> I think this is now exported in userspace, right Narendra?
>
Right. It is in the mainline kernel.
( commit 911e1c9b05a8e3559a7aa89083930700a0b9e7ee)
--
With regards,
Narendra K
^ permalink raw reply
* [PATCH] [ARM] dove: add support for CM-A510 machine.
From: saeed bishara @ 2010-10-07 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286436985-24224-1-git-send-email-kostyas@compulab.co.il>
On Thu, Oct 7, 2010 at 9:36 AM, Konstantin Sinyuk
<kostyas@compulab.co.il> wrote:
> Signed-off-by: Konstantin Sinyuk <kostyas@compulab.co.il>
> Signed-off-by: Mike Rapoport <mike@compulab.co.il>
> ---
> ?arch/arm/mach-dove/Kconfig ? | ? ?6 +++
> ?arch/arm/mach-dove/Makefile ?| ? ?1 +
> ?arch/arm/mach-dove/cm-a510.c | ? 96 ++++++++++++++++++++++++++++++++++++++++++
> ?3 files changed, 103 insertions(+), 0 deletions(-)
> ?create mode 100644 arch/arm/mach-dove/cm-a510.c
>
> diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
> index 3b9a32a..a4ed390 100644
> --- a/arch/arm/mach-dove/Kconfig
> +++ b/arch/arm/mach-dove/Kconfig
> @@ -9,6 +9,12 @@ config MACH_DOVE_DB
> ? ? ? ? ?Say 'Y' here if you want your kernel to support the
> ? ? ? ? ?Marvell DB-MV88AP510 Development Board.
>
> + config MACH_CM_A510
> + ? ? ? bool "CompuLab CM-A510 Board"
> + ? ? ? help
> + ? ? ? ? Say 'Y' here if you want your kernel to support the
> + ? ? ? ? CompuLab CM-A510 Board.
> +
> ?endmenu
>
> ?endif
> diff --git a/arch/arm/mach-dove/Makefile b/arch/arm/mach-dove/Makefile
> index 7ab3be5..f74f549 100644
> --- a/arch/arm/mach-dove/Makefile
> +++ b/arch/arm/mach-dove/Makefile
> @@ -1,3 +1,4 @@
> ?obj-y ? ? ? ? ? ? ? ? ? ? ? ? ?+= common.o addr-map.o irq.o pcie.o
>
> ?obj-$(CONFIG_MACH_DOVE_DB) ? ? += dove-db-setup.o
> +obj-$(CONFIG_MACH_CM_A510) ? ? += cm-a510.o
> diff --git a/arch/arm/mach-dove/cm-a510.c b/arch/arm/mach-dove/cm-a510.c
> new file mode 100644
> index 0000000..321c961
> --- /dev/null
> +++ b/arch/arm/mach-dove/cm-a510.c
> @@ -0,0 +1,96 @@
> +/*
> + * arch/arm/mach-dove/cm-a510.c
> + *
> + * Copyright (C) 2010 CompuLab, Ltd.
> + * Konstantin Sinyuk <kostyas@compulab.co.il>
> + *
> + * Based on Marvell DB-MV88AP510-BP Development Board Setup
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. ?This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/ata_platform.h>
> +#include <linux/mv643xx_eth.h>
> +#include <linux/spi/spi.h>
> +#include <linux/spi/flash.h>
> +
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +
> +#include <mach/dove.h>
> +
> +#include "common.h"
> +
> +static struct mv643xx_eth_platform_data cm_a510_ge00_data = {
> + ? ? ? .phy_addr ? ? ? = MV643XX_ETH_PHY_ADDR_DEFAULT,
> +};
> +
> +static struct mv_sata_platform_data cm_a510_sata_data = {
> + ? ? ? .n_ports ? ? ? ?= 1,
> +};
> +
> +/*
> + * SPI Devices:
> + * SPI0: 1M Flash Winbond w25q32bv
> + */
> +static const struct flash_platform_data cm_a510_spi_flash_data = {
> + ? ? ? .type ? ? ? ? ? = "w25q32bv",
> +};
> +
> +static struct spi_board_info __initdata cm_a510_spi_flash_info[] = {
> + ? ? ? {
> + ? ? ? ? ? ? ? .modalias ? ? ? = "m25p80",
> + ? ? ? ? ? ? ? .platform_data ?= &cm_a510_spi_flash_data,
> + ? ? ? ? ? ? ? .irq ? ? ? ? ? ?= -1,
> + ? ? ? ? ? ? ? .max_speed_hz ? = 20000000,
> + ? ? ? ? ? ? ? .bus_num ? ? ? ?= 0,
> + ? ? ? ? ? ? ? .chip_select ? ?= 0,
> + ? ? ? },
> +};
> +
> +static int __init cm_a510_pci_init(void)
> +{
> + ? ? ? if (machine_is_cm_a510())
> + ? ? ? ? ? ? ? dove_pcie_init(1, 1);
> +
> + ? ? ? return 0;
> +}
> +
> +subsys_initcall(cm_a510_pci_init);
> +
> +/* Board Init */
> +static void __init cm_a510_init(void)
> +{
> + ? ? ? /*
> + ? ? ? ?* Basic Dove setup. Needs to be called early.
> + ? ? ? ?*/
> + ? ? ? dove_init();
> +
> + ? ? ? dove_ge00_init(&cm_a510_ge00_data);
> + ? ? ? dove_ehci0_init();
> + ? ? ? dove_ehci1_init();
> + ? ? ? dove_sata_init(&cm_a510_sata_data);
> + ? ? ? dove_sdio0_init();
> + ? ? ? dove_sdio1_init();
> + ? ? ? dove_spi0_init();
> + ? ? ? dove_spi1_init();
> + ? ? ? dove_uart0_init();
> + ? ? ? dove_uart1_init();
> + ? ? ? dove_i2c_init();
> + ? ? ? spi_register_board_info(cm_a510_spi_flash_info,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ARRAY_SIZE(cm_a510_spi_flash_info));
Konstantin, are you sure your board has all the above interfaces?
other than that the patch looks fine to me.
> +}
> +
> +MACHINE_START(CM_A510, "Compulab CM-A510 Board")
> + ? ? ? .phys_io ? ? ? ?= DOVE_SB_REGS_PHYS_BASE,
> + ? ? ? .io_pg_offst ? ?= ((DOVE_SB_REGS_VIRT_BASE) >> 18) & 0xfffc,
> + ? ? ? .boot_params ? ?= 0x00000100,
> + ? ? ? .init_machine ? = cm_a510_init,
> + ? ? ? .map_io ? ? ? ? = dove_map_io,
> + ? ? ? .init_irq ? ? ? = dove_init_irq,
> + ? ? ? .timer ? ? ? ? ?= &dove_timer,
> +MACHINE_END
> --
> 1.7.0.4
^ permalink raw reply
* Re: [Qemu-devel] Re: [PATCH 09/11] i386: avoid a write only variable
From: malc @ 2010-10-07 17:44 UTC (permalink / raw)
To: Blue Swirl; +Cc: Paolo Bonzini, qemu-devel
In-Reply-To: <AANLkTikTXnq7N+--tmgZwnimmw31Nv2g97T5KqVWMOQ8@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1114 bytes --]
On Thu, 7 Oct 2010, Blue Swirl wrote:
> On Thu, Oct 7, 2010 at 8:27 AM, malc <av1474@comtv.ru> wrote:
> > On Thu, 7 Oct 2010, Paolo Bonzini wrote:
> >
> >> On 10/06/2010 11:34 PM, Blue Swirl wrote:
> >> > Compiling with GCC 4.6.0 20100925 produced warnings:
> >> > /src/qemu/target-i386/op_helper.c: In function 'switch_tss':
> >> > /src/qemu/target-i386/op_helper.c:283:53: error: variable 'new_trap'
> >> > set but not used [-Werror=unused-but-set-variable]
> >> >
> >> > Fix by deleting the variable.
> >>
> >> Again, this warning tells us the emulation is incorrect, so it's wrong to
> >> remove it.
> >>
> >
> > http://support.amd.com/us/Processor_TechDocs/24593.pdf
> >
> > 12.2.5
> > T (Trap) Bit--■Bit 0 of byte 64h, static field. This bit, when set to1,
> > causes a debug exception (#DB) to occur on a task switch. See "Beakpoint
> > Instruction (INT3)" page 340 for additional information.
>
> Yes, I read that before making the patch. But page 340 didn't seem to
> give any relevant information.
13.2.4 Breakpoint Instruction (INT3)
Is what was referred to apparently.
--
mailto:av1474@comtv.ru
^ permalink raw reply
* Re: git log doesn't allow %x00 in custom format anymore?
From: Erik Faye-Lund @ 2010-10-07 17:43 UTC (permalink / raw)
To: Jeff King; +Cc: Kirill Likhodedov, Johannes Sixt, git
In-Reply-To: <AANLkTimYVNNjhaqUHjoVOV-fQBhcENKn7cyj10qcZ+MW@mail.gmail.com>
On Thu, Oct 7, 2010 at 7:41 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> On Thu, Oct 7, 2010 at 7:29 PM, Jeff King <peff@peff.net> wrote:
>> On Thu, Oct 07, 2010 at 07:18:18PM +0400, Kirill Likhodedov wrote:
>>
>>> Thanks for pointing that out.
>>> I confirm that on Mac OS X that happens for rev-list as well.
>>>
>>> # git log --pretty=format:foo%x00bar HEAD -1 | od -c
>>> 0000000 f o o \0 b a r
>>> 0000007
>>>
>>> # git rev-list --pretty=format:foo%x00bar HEAD -1 | od -c
>>> 0000000 c o m m i t 2 3 6 0 1 a 2 c 3
>>> 0000020 e 4 6 4 a 4 4 7 9 f 1 7 7 4 e 3
>>> 0000040 6 e a 5 b 9 5 8 b 4 6 0 5 2 1 \n
>>> 0000060 f o o \n
>>> 0000064
>>
>> Ugh. Even worse, it does print with --graph, which uses a slightly
>> different code path.
>>
>> $ git rev-list --graph -1 --format=foo%x00bar HEAD | cat -A
>> * commit 81d866a6a213d5524ce389369377ba3529461e1b$
>> |\ foo^@bar$
>>
>> I am inclined to call the rev-list behavior a bug, and the fix is
>> probably:
>>
>> diff --git a/builtin/rev-list.c b/builtin/rev-list.c
>> index efe9360..3b2dca0 100644
>> --- a/builtin/rev-list.c
>> +++ b/builtin/rev-list.c
>> @@ -147,8 +147,10 @@ static void show_commit(struct commit *commit, void *data)
>> }
>> } else {
>> if (revs->commit_format != CMIT_FMT_USERFORMAT ||
>> - buf.len)
>> - printf("%s%c", buf.buf, info->hdr_termination);
>> + buf.len) {
>> + fwrite(buf.buf, 1, buf.len, stdout);
>> + putchar(info->hdr_termination);
>> + }
>> }
>> strbuf_release(&buf);
>> } else {
>
> This gives me a bit of a deja-vu: 1fb5fdd
>
Never mind that, I'm a bit too tired and got struck with a bit of paranoia :P
^ permalink raw reply
* Re: gspca, audio and ov534: regression.
From: Jean-Francois Moine @ 2010-10-07 17:44 UTC (permalink / raw)
To: Antonio Ospite; +Cc: linux-media
In-Reply-To: <20101006165337.9c60bb95.ospite@studenti.unina.it>
On Wed, 6 Oct 2010 16:53:37 +0200
Antonio Ospite <ospite@studenti.unina.it> wrote:
> > PS3 Eye audio is working with linux-2.6.33.7 it is broken in
> > linux-2.6.35.7 already, I'll try to further narrow down the
> > interval. Ah, alsamixer doesn't work even when the device is OK in
> > pulseaudio...
>
> I was wrong, the audio part works even in 2.6.36-rc6 but _only_ when
> the webcam is plugged in from boot, could this have to do with the
> order gspca and snd-usb-audio are loaded?
Hi Antonio,
If you still have a kernel 2.6.33, may you try my test version (tarball
in my web page)? As it contain only the gspca stuff, this may tell if
the problem is in gspca or elsewhere in the kernel.
Best regards.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* Re: [GIT PULL] core kernel fixes
From: Paul E. McKenney @ 2010-10-07 17:42 UTC (permalink / raw)
To: Ingo Molnar
Cc: Eric Dumazet, Linus Torvalds, linux-kernel, Peter Zijlstra,
Andrew Morton, Thomas Gleixner
In-Reply-To: <20101007081100.GA16539@elte.hu>
On Thu, Oct 07, 2010 at 10:11:00AM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
>
> > On Wed, Oct 06, 2010 at 08:20:49PM +0200, Ingo Molnar wrote:
> > >
> > > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> > >
> > > > Ingo, I have this queued up at:
> > > >
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git rcu/urgent
> > > >
> > > > It passes targeted testing. If Eric is OK with it, it is ready to be
> > > > pulled. At least as soon as kernel.org gets it out to the mirrors.
> > > > Commmit 773e3f9357.
> > >
> > > Now that the original fix is in Linus's tree, can the followup commits
> > > wait until v2.6.37?
> > >
> > > Linus, Paul, what's your preference?
> >
> > I am fine either way.
>
> Ok, Linus released -rc7 which is probably the last -rc so to reduce
> final-rc code flux i have pulled your fix into tip:core/rcu, for
> v2.6.37.
Ah, good, thank you! I am rebasing on top of that. Here is hoping that
this approach quiets down the conflict in -next as well. ;-)
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 13/15] cifs: convert cifsFileInfo->count to non-atomic counter
From: Jeff Layton @ 2010-10-07 17:42 UTC (permalink / raw)
To: Jeff Layton
Cc: Steve French, Suresh Jayaraman, linux-cifs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101007125932.4506f3e6-xSBYVWDuneFaJnirhKH9O4GKTjYczspe@public.gmane.org>
On Thu, 7 Oct 2010 12:59:32 -0400
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> For instance:
>
> + if (!atomic_dec_and_lock(&cifs_file->count, &cifs_file_list_lock))
> + return;
> +
> + /* count can be incremented inside the lock, so must check again */
> + if (atomic_read(&cifs_file->count) > 0) {
> + spin_unlock(&cifs_file_list_lock);
> + return;
> + }
>
...oh and to make matters worse, the above code is still racy if the
count can be incremented outside the lock too.
I think we need to try to keep this code as simple as possible with
clear, unambiguous locking rules around a simple counter.
--
Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
^ permalink raw reply
* Re: Linux 2.6.36-rc7
From: Alan Cox @ 2010-10-07 18:07 UTC (permalink / raw)
To: Eric Paris
Cc: Tvrtko Ursulin, Linus Torvalds, Linux Kernel Mailing List, agruen
In-Reply-To: <1286472835.2656.15.camel@dhcp231-98.rdu.redhat.com>
> I see two possibilities off the top of my head:
>
> I could just slap an (unused) priority field onto the end of the
> fanotify_init() syscall (assuming Linus doesn't murder me) so we can
> build that support out with explicit priorities down the line, which I
> think might be overkill, or
>
> The other option (without breaking ABI as it stands today) is to define
> some set of the fanotify_init() flags to be a priority field, we've got
> 32 bits and only use 2 of them so giving 4-8 bits of that as a priority
> (next cycle) isn't an issue and can be easily backwards compatible.
Except you've then got a magic release that works differently to every
other release afterwards and which sods law says will get shipped by some
big vendor. Both your proposals are "we got the API wrong, lets have one
kernel that is special", that isn't good in the bigger scheme of things
and will have if kernel 2.6.blah then crap forced into bits of app/lib
code forever.
Given two chunks of "oh dear" last minute stuff would it be safer to
simply punt and just pull the syscall/prototype itself (leaving the rest)
for the release. That can go into the first pass of the next kernel tree,
and if it the fixes and priority bits all work out may well then be tiny
enough for -stable.
Alan
^ permalink raw reply
* Re: [PATCH 5/7] Add MCI card support to barebox
From: Juergen Beisert @ 2010-10-07 17:39 UTC (permalink / raw)
To: Sascha Hauer; +Cc: barebox
In-Reply-To: <20101007165959.GJ28242@pengutronix.de>
Sascha Hauer wrote:
> On Thu, Oct 07, 2010 at 06:00:06PM +0200, Juergen Beisert wrote:
> > Sascha Hauer wrote:
> > > On Thu, Oct 07, 2010 at 03:24:16PM +0200, Juergen Beisert wrote:
> > > > This adds the basic framework to handle MCI cards in barebox.
> > > >
> > > > Signed-off-by: Juergen Beisert <jbe@pengutronix.de>
> > > > ---
> > > > drivers/Kconfig | 1 +
> > > > drivers/Makefile | 1 +
> > > > drivers/mci/Kconfig | 30 ++
> > > > drivers/mci/Makefile | 1 +
> > > > drivers/mci/mci-core.c | 1308
> > > > ++++++++++++++++++++++++++++++++++++++++++++++++ include/mci.h
> > > > | 230 +++++++++
> > > > 6 files changed, 1571 insertions(+), 0 deletions(-)
> > > > create mode 100644 drivers/mci/Kconfig
> > > > create mode 100644 drivers/mci/Makefile
> > > > create mode 100644 drivers/mci/mci-core.c
> > > > create mode 100644 include/mci.h
> > >
> > > This whole patch looks quite good.
> > > Please add some linebreaks in mci-core.c. I don't want strict 80
> > > character lines, but some lines are really long.
> > >
> > > [snip]
> > >
> > > > +static int mci_probe(struct device_d *mci_dev)
> > > > +{
> > > > + struct mci *mci;
> > > > + int rc;
> > > > +
> > > > + mci = xzalloc(sizeof(struct mci));
> > > > + mci_dev->priv = mci;
> > > > +
> > > > +#ifdef CONFIG_MCI_STARTUP
> > > > + /* if enabled, probe the attached card immediately */
> > > > + rc = mci_card_probe(mci_dev);
> > > > + if (rc == -ENODEV) {
> > > > + /*
> > > > + * If it fails, add the 'probe' parameter to give the user
> > > > + * a chance to insert a card and try again. Note: This may fail
> > > > + * systems that rely on the MCI card for startup (for the
> > > > + * persistant environment for example)
> > > > + */
> > > > + rc = add_mci_parameter(mci_dev);
> > > > + if (rc != 0) {
> > > > + pr_err("Failed to add 'probe' parameter to the MCI device\n");
> > > > + goto on_error;
> > > > + }
> > > > + }
> > > > +#endif
> > > > +
> > > > +#ifndef CONFIG_MCI_STARTUP
> > >
> > > #else instead?
> > >
> > > > + /* add params on demand */
> > > > + rc = add_mci_parameter(mci_dev);
> > > > + if (rc != 0) {
> > > > + pr_err("Failed to add 'probe' parameter to the MCI device\n");
> > > > + goto on_error;
> > > > + }
> > > > +#endif
> > > > +
> > > > + return rc;
> > > > +
> > > > +on_error:
> > > > + free(mci);
> > > > + return rc;
> > > > +}
> > > > +
> > >
> > > [snip]
> > >
> > > > +
> > > > +/** host information */
> > > > +struct mci_platformdata {
> > > > + struct device_d *hw_dev; /**< the host MCI hardware device */
> > > > + unsigned voltages;
> > > > + unsigned host_caps; /**< Host's interface capabilities, refer
> > > > MMC_VDD_* and FIXME */ + unsigned f_min; /**< host interface lower
> > > > limit */ + unsigned f_max; /**< host interface upper limit */
> > > > + unsigned clock; /**< Current clock used to talk to the card */
> > > > + unsigned bus_width; /**< used data bus width to the card */
> > > > +
> > > > + int (*init)(struct device_d*, struct device_d*); /**< init the host
> > > > interface */ + void (*set_ios)(struct device_d*, struct device_d*,
> > > > unsigned, unsigned); /**< change host interface settings */ + int
> > > > (*send_cmd)(struct device_d*, struct mci_cmd*, struct
> > > > mci_data*); /**< handle a command */ +};
> > >
> > > I prefer this struct named mci_host, this seems to match better what it
> > > actually is.
> >
> > Hmm, no, its not a "host". It is the MMC/SD card instance. The host is
> > more the interface, isn't it (at least for me)?
>
> It's a host at least in the Linux terminology.
Yes. So, we name the platform like data of the MCI card device
instance "mci_host".
host device
-----------
hw_device
->priv: points to drivers private data
names are: "s3c_mci_host" or "stm_mci_host"
->platform_data: points to data provided by the platform
names are: "s3c_mci_platform_data" or "stm_mci_platform_data"
mci device
----------
mci_device
->priv: points to mci layer's private data
name is: "mci_data"
->platform_data: points to data provided by the host device
name is: "mci_platformdata"
name should be: "mci_host"
"host" in the name sounds IMHO wrong here. I'm not happy about that, but its
okay. I will change the name.
> > > For the convenience of drivers set init/set_ios/send_cmd
> > > functions should be passed a pointer to the mci_host, not the device,
> > > because that's what they actually registered. I already prepared a
> > > patch for this, I'll send it in a seperate mail.
> >
> > I tried to layering the devices:
> >
> > disk_device -> knows how to handle disk drives and partition tables
> >
> > mci_device -> knows how to probe and manage MMC/SD cards
> >
> > hw_device -> knows how to transfer data
> >
> > Most functions in the hw_device layer do not need access to any other
> > structure data than their own device (okay, there is a exception). So, I
> > tried to keep it simple.
>
> I didn't change the underlying structure, only the pointer which is
> passed to the functions.
Sure.
jbe
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | Phone: +49-8766-939 228 |
Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: git log doesn't allow %x00 in custom format anymore?
From: Erik Faye-Lund @ 2010-10-07 17:41 UTC (permalink / raw)
To: Jeff King; +Cc: Kirill Likhodedov, Johannes Sixt, git
In-Reply-To: <20101007172939.GA12130@sigill.intra.peff.net>
On Thu, Oct 7, 2010 at 7:29 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Oct 07, 2010 at 07:18:18PM +0400, Kirill Likhodedov wrote:
>
>> Thanks for pointing that out.
>> I confirm that on Mac OS X that happens for rev-list as well.
>>
>> # git log --pretty=format:foo%x00bar HEAD -1 | od -c
>> 0000000 f o o \0 b a r
>> 0000007
>>
>> # git rev-list --pretty=format:foo%x00bar HEAD -1 | od -c
>> 0000000 c o m m i t 2 3 6 0 1 a 2 c 3
>> 0000020 e 4 6 4 a 4 4 7 9 f 1 7 7 4 e 3
>> 0000040 6 e a 5 b 9 5 8 b 4 6 0 5 2 1 \n
>> 0000060 f o o \n
>> 0000064
>
> Ugh. Even worse, it does print with --graph, which uses a slightly
> different code path.
>
> $ git rev-list --graph -1 --format=foo%x00bar HEAD | cat -A
> * commit 81d866a6a213d5524ce389369377ba3529461e1b$
> |\ foo^@bar$
>
> I am inclined to call the rev-list behavior a bug, and the fix is
> probably:
>
> diff --git a/builtin/rev-list.c b/builtin/rev-list.c
> index efe9360..3b2dca0 100644
> --- a/builtin/rev-list.c
> +++ b/builtin/rev-list.c
> @@ -147,8 +147,10 @@ static void show_commit(struct commit *commit, void *data)
> }
> } else {
> if (revs->commit_format != CMIT_FMT_USERFORMAT ||
> - buf.len)
> - printf("%s%c", buf.buf, info->hdr_termination);
> + buf.len) {
> + fwrite(buf.buf, 1, buf.len, stdout);
> + putchar(info->hdr_termination);
> + }
> }
> strbuf_release(&buf);
> } else {
This gives me a bit of a deja-vu: 1fb5fdd
Also, fwriting like that to stdout might be a bit troublesome on
Windows because the string won't end up going through our
ANSI-emulation.
^ 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.