* [PATCH RFC 0/8] Signal: harmonize syscall restart logic
From: Jonas Bonn @ 2011-10-23 10:19 UTC (permalink / raw)
To: linux-kernel, linux-arch; +Cc: Jonas Bonn
I've been looking into trying to harmonize the architecture specific
signal handling code. With a couple of helper functions to mask some
of the architecture specific bits, the code for do_signal and handle_signal
(implemented by essentially everybody) start to look identical across
all arch's and could likely be made generic.
The big helper is the one in this series. This one moves the syscall
restart logic out to a common helper. The arch specific bit here is
the register manipulations required to actually effect the restart;
this patch series moves those manipulations to the asm/syscall.h header
which already attempts to define a generic syscall interface for several
arch's today.
Where this series remains an RFC is due to a couple of open questions:
i) ARM (and a few arch's copied from it) does its restart logic in two
steps so that a debugger can intervene; is there still value in
this approach or would the single step approach in this patch series
be sufficient for ARM (and others)?
ii) The syscall.h interface requires that the information needed to do
the register manipulations be in the pt_regs struct. This isn't
the case for all arch's today. Are there any issues with putting that
info into pt_regs for those arch's?
With the rest of the cleanups in this series it currently comes to 64
patches, so I'm just posting a couple of the syscall restart patches
now for comment in order not to flood the lists. I'll post the remainder
of the series later based on the feedback from this series.
/Jonas
Jonas Bonn (8):
signal: introduce generic syscall restart logic
blackfin: implement syscall restart generically
frv: implement syscall restart generically
mips: implement syscall restart generically
x86: implement syscall restart generically
m68k: implement syscall restart generically
ia64: implement syscall restart generically
tile: implement syscall restart generically
arch/blackfin/include/asm/syscall.h | 26 +++++++++-
arch/blackfin/kernel/signal.c | 47 +-----------------
arch/frv/include/asm/syscall.h | 23 ++++++++-
arch/frv/kernel/signal.c | 48 +-----------------
arch/ia64/include/asm/syscall.h | 21 ++++++++
arch/ia64/kernel/signal.c | 54 +--------------------
arch/m68k/include/asm/syscall.h | 87 +++++++++++++++++++++++++++++++++
arch/m68k/kernel/signal_mm.c | 45 +----------------
arch/m68k/kernel/signal_no.c | 46 +----------------
arch/mips/include/asm/syscall.h | 91 +++++++++++++++++++++++++++++++++++
arch/mips/kernel/signal.c | 40 +--------------
arch/tile/include/asm/syscall.h | 28 ++++++++++-
arch/tile/kernel/signal.c | 52 ++------------------
arch/x86/include/asm/syscall.h | 21 ++++++++
arch/x86/kernel/signal.c | 43 +---------------
include/asm-generic/syscall.h | 46 +++++++++++++++++-
include/linux/signal.h | 3 +
kernel/signal.c | 72 +++++++++++++++++++++++++++-
18 files changed, 435 insertions(+), 358 deletions(-)
create mode 100644 arch/m68k/include/asm/syscall.h
create mode 100644 arch/mips/include/asm/syscall.h
--
1.7.5.4
^ permalink raw reply
* Re: [PATCH 2/2] drm/i915: properly prefault for pread/pwrite
From: Daniel Vetter @ 2011-10-23 10:19 UTC (permalink / raw)
To: Chris Wilson, Keith Packard; +Cc: Daniel Vetter, intel-gfx, stable
In-Reply-To: <20111023101830.GE2953@phenom.ffwll.local>
Oosp, forgotten to actually put Keith on the To: ... not enough coffee,
yet.
-Daniel
On Sun, Oct 23, 2011 at 12:18:30PM +0200, Daniel Vetter wrote:
> Hi Keith,
>
> This patch isn't in your -next pull. This papers over a spurious -EFAULT
> in the pwrite/pread paths that actually gets hit in the wild. The real fix
> in the form of a almost complete rewrite of the pwrite/pread paths won't
> be ready for 3.2.
>
> Do you want me to implement Chris' beautification suggestion? The code
> as-is is copied over from the pagecache prefault helper. Otherwise please
> consider merging for 3.2.
>
> Yours, Daniel
>
> On Wed, Sep 28, 2011 at 12:24:04PM +0100, Chris Wilson wrote:
> > > + if (ret == 0) {
> > > + if (((unsigned long)uaddr & PAGE_MASK) !=
> > > + ((unsigned long)end & PAGE_MASK))
> > This is a little ugly. Perhaps,
> >
> > #define page_align(addr) ((unsigned long)addr & PAGE_MASK)
> > if (page_align(uaddr) != page_align(end))
> >
> > Otherwise, both are
> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> > -Chris
> >
> > --
> > Chris Wilson, Intel Open Source Technology Centre
>
> --
> Daniel Vetter
> Mail: daniel@ffwll.ch
> Mobile: +41 (0)79 365 57 48
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* Re: [PATCH 00/22] Refactor to accept NUL in commit messages
From: Nguyen Thai Ngoc Duy @ 2011-10-23 10:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, peff, Ævar Arnfjörð
In-Reply-To: <7vehy459bg.fsf@alter.siamese.dyndns.org>
On Sun, Oct 23, 2011 at 8:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> On Sun, Oct 23, 2011 at 4:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>>> The low level object format of our commit is textual header fields, each
>>> of which is terminated with a LF, followed by a LF to mark the end of
>>> header fields, and then opaque payload that can contain any bytes. It does
>>> not forbid a non-Git application to reuse the object store infrastructure
>>> to store ASN.1 binary goo there, and the low level interface we give such
>>> as cat-file is a perfectly valid way to inspect such a "commit" object.
>>
>> cat-file is fine, commit-tree (or any commands that call
>> commit_tree()) cuts at NUL though.
>> I wonder how git processes commit messages in utf-16.
>
> That is exactly what I am saying.
>
> Perhaps you didn't either read or understand what you omitted from your
> quoting; otherwise you even wouldn't have brought up utf-16.
>
> Let me requote that part for you.
>
>> But when it comes to "Git" Porcelains (e.g. the log family of commands),
>> we do assume people do not store random binary byte sequences in commits,
>> and we do take advantage of that assumption by splitting each "line" at
>> LF, indenting them with 4 spaces, etc. In other words, a commit log in the
>> Git context _is_ pretty much text and not arbitrary byte sequence.
>
> Think what would cutting at a byte whose value is 012 and adding four
> bytes whose values are 040 to each of "lines" that formed with such
> cutting do to UTF-16 goo, even if it does not contain any NUL byte. As far
> as Git Porcelains are concerned, it is no different from random binary
> byte sequences.
>
I'm sorry. The utf-16 was an afterthought when I was nearly finished
with the reply and already cut that quote.
The assumption that people do not store random binary byte sequences
in commits sort of conflicts with "encoding" field in the commit
header though. The assumption is documented in i18n.txt. I guess it's
just me who did not read document carefully. But maybe it's good to
stop people from shooting themselves in this case (i.e. setting
encoding to utf-16 or similar).
--
Duy
^ permalink raw reply
* Re: [PATCH 1/3] drm/i915: Ivybridge still has fences!
From: Jesse Barnes @ 2011-10-23 10:18 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, intel-gfx, stable
In-Reply-To: <20111023101200.GC2953@phenom.ffwll.local>
On Sun, 23 Oct 2011 12:12:00 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Oct 10, 2011 at 10:58:22AM -0700, Jesse Barnes wrote:
> > On Sun, 9 Oct 2011 21:52:01 +0200
> > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > > So don't forget to restore them on resume and dump them into
> > > the error state.
> >
> > This should probably just be >= 6 instead; I don't think we're
> > getting rid of fences anytime soon.
>
> As discussed on irc >= 6 is a bit hard to do in a switch
> statement ;-) Do you want me to resend the patches using the gcc
> ranged switch extension suggested by Adam Jackson (i.e. 6..UINT_MAX)?
> Or can you slap your r-b on them as-is?
I was suggesting that you convert it to an if ladder with the >= 6 at
the top. That should be a separate patch though.
Jesse
^ permalink raw reply
* Re: [PATCH 2/2] drm/i915: properly prefault for pread/pwrite
From: Daniel Vetter @ 2011-10-23 10:18 UTC (permalink / raw)
To: Chris Wilson; +Cc: Daniel Vetter, intel-gfx, stable
In-Reply-To: <f80fcd$212d29@fmsmga001.fm.intel.com>
Hi Keith,
This patch isn't in your -next pull. This papers over a spurious -EFAULT
in the pwrite/pread paths that actually gets hit in the wild. The real fix
in the form of a almost complete rewrite of the pwrite/pread paths won't
be ready for 3.2.
Do you want me to implement Chris' beautification suggestion? The code
as-is is copied over from the pagecache prefault helper. Otherwise please
consider merging for 3.2.
Yours, Daniel
On Wed, Sep 28, 2011 at 12:24:04PM +0100, Chris Wilson wrote:
> > + if (ret == 0) {
> > + if (((unsigned long)uaddr & PAGE_MASK) !=
> > + ((unsigned long)end & PAGE_MASK))
> This is a little ugly. Perhaps,
>
> #define page_align(addr) ((unsigned long)addr & PAGE_MASK)
> if (page_align(uaddr) != page_align(end))
>
> Otherwise, both are
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* Re: WARNING: at fs/dcache.c:2549 prepend_path+0x164/0x170() [Root dentry has weird name <>]
From: Linus Torvalds @ 2011-10-23 10:16 UTC (permalink / raw)
To: Al Viro
Cc: linux-kernel, Randy Dunlap, David Howells, Jeff Layton,
Pawel Sikora
In-Reply-To: <1633484.nypxIFiqdQ@pawels>
Al, any idea on this one?
mnt->mnt_parent should equal mnt only for a root dentry, but detaching
mount-points and mnt_clone() ends up doing it too, so maybe there is
some way where that "global_root" test triggers on a dentry that
hasn't been allocated with d_alloc_root().
I wonder how useful that warning is at all.
Linus
On Thu, Oct 20, 2011 at 5:49 PM, Pawel Sikora <pluto@agmk.net> wrote:
> Hi,
>
> during the 3.0.6 kernel stressing on dual-opteron machine i've noticed warnings in dmesg.
> bugzilla.kernel.org is down currently, so i'm CCing last fs/dcache.c commiters.
> i hope that this shortlog will help you.
>
> BR,
> Paweł.
>
> (...)
> Oct 14 15:52:36 odra kernel: [ 18.710510] igb: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
> Oct 14 15:52:36 odra kernel: [ 18.713039] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
> Oct 14 15:52:39 odra kernel: [ 21.885578] FS-Cache: Loaded
> Oct 14 15:52:39 odra kernel: [ 21.898297] Registering the id_resolver key type
> Oct 14 15:52:39 odra kernel: [ 21.898325] FS-Cache: Netfs 'nfs' registered for caching
> Oct 14 15:52:59 odra kernel: [ 26.110041] eth0: no IPv6 routers present
> Oct 14 15:53:02 odra kernel: [ 29.363344] eth1: no IPv6 routers present
> Oct 15 11:06:50 odra kernel: [69257.064455] process `sysctl' is using deprecated sysctl (syscall) net.ipv6.neigh.default.retrans_time; Use net.ipv6.neigh.default.retrans_time_ms instead.
> Oct 18 19:40:36 odra kernel: [359283.045721] ------------[ cut here ]------------
> Oct 18 19:40:36 odra kernel: [359283.045731] WARNING: at fs/dcache.c:2549 prepend_path+0x164/0x170()
> Oct 18 19:40:36 odra kernel: [359283.045734] Hardware name: H8DGU
> Oct 18 19:40:36 odra kernel: [359283.045736] Root dentry has weird name <>
> Oct 18 19:40:36 odra kernel: [359283.045737] Modules linked in: nfs fscache binfmt_misc nfsd lockd exportfs nfs_acl auth_rpcgss sunrpc ipmi_si ipmi_devintf ipmi_msghandler sch_sfq iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter xt_TCPMSS xt_tcpudp iptable_mangle ip_tables ip6table_filter ip6_tables x_tables ext4 jbd2 crc16 raid0 dm_mod autofs4 dummy usbhid hid ide_cd_mod cdrom ata_generic pata_acpi ohci_hcd pata_atiixp ide_pci_generic ssb pcmcia sp5100_tco pcmcia_core ehci_hcd amd64_edac_mod pcspkr edac_core evdev mmc_core atiixp igb i2c_piix4 i2c_core ide_core edac_mce_amd processor ghes usbcore psmouse serio_raw button k10temp hed hwmon dca sg sd_mod crc_t10dif raid1 md_mod ext3 jbd mbcache ahci libahci libata scsi_mod [last unloaded: scsi_wait_scan]
> Oct 18 19:40:36 odra kernel: [359283.045799] Pid: 8349, comm: pidof Not tainted 3.0.6-dirty #2
> Oct 18 19:40:36 odra kernel: [359283.045802] Call Trace:
> Oct 18 19:40:36 odra kernel: [359283.045812] [<ffffffff8104718a>] warn_slowpath_common+0x7a/0xb0
> Oct 18 19:40:36 odra kernel: [359283.045817] [<ffffffff81047261>] warn_slowpath_fmt+0x41/0x50
> Oct 18 19:40:36 odra kernel: [359283.045822] [<ffffffff81415c74>] ? __slab_free+0xfc/0x105
> Oct 18 19:40:36 odra kernel: [359283.045825] [<ffffffff8114bac4>] prepend_path+0x164/0x170
> Oct 18 19:40:36 odra kernel: [359283.045829] [<ffffffff8114bb27>] path_with_deleted+0x57/0xa0
> Oct 18 19:40:36 odra kernel: [359283.045831] [<ffffffff8114bc21>] d_path+0xb1/0xe0
> Oct 18 19:40:36 odra kernel: [359283.045837] [<ffffffff811906db>] proc_pid_readlink+0x8b/0xf0
> Oct 18 19:40:36 odra kernel: [359283.045841] [<ffffffff8113baa6>] sys_readlinkat+0xa6/0xb0
> Oct 18 19:40:36 odra kernel: [359283.045844] [<ffffffff8113bac6>] sys_readlink+0x16/0x20
> Oct 18 19:40:36 odra kernel: [359283.045849] [<ffffffff81421f7b>] system_call_fastpath+0x16/0x1b
> Oct 18 19:40:36 odra kernel: [359283.045851] ---[ end trace b5522e2b9acb171d ]---
> (...)
>
>
^ permalink raw reply
* Re: copy_*_user
From: H. Peter Anvin @ 2011-10-23 10:15 UTC (permalink / raw)
To: Xin Tong; +Cc: Américo Wang, linux-kernel
In-Reply-To: <CALKntY0222DBU88W=j0Y2FpN7NRMSxmDk4XKy-m+keri4Gcu_A@mail.gmail.com>
On 10/23/2011 11:23 AM, Xin Tong wrote:
> I found that __copy_from_user_ll(void *to, const void __user *from,
> unsigned long n) eventually calls some asm which use mov and rep on
> the passed-in to & from pointers. This is in kernel mode and to & from
> are virtual addresses ? are not the kernel accessing physical RAM
> directly ( without pagetable ) ?
No. What gave you that idea?
-hpa
^ permalink raw reply
* Re: [PATCH] drm/i915: forcewake warning fixes in debugfs
From: Daniel Vetter @ 2011-10-23 10:13 UTC (permalink / raw)
To: Ben Widawsky, Keith Packard; +Cc: intel-gfx
In-Reply-To: <20111008213215.GA2982@phenom.ffwll.local>
Hi Keith,
This patch isn't in your -next pull request. Please consider merging for
3.2.
Yours, Daniel
On Sat, Oct 08, 2011 at 11:32:34PM +0200, Daniel Vetter wrote:
> On Wed, Oct 05, 2011 at 11:44:54AM -0700, Ben Widawsky wrote:
> > Some more unsafe debugfs access are fixed with this patch. I tested all reads,
> > but didn't thoroughly test the writes.
> >
> > Cc: "Nicolas Kalkhof" <nkalkhof@web.de>
> > Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> --
> Daniel Vetter
> Mail: daniel@ffwll.ch
> Mobile: +41 (0)79 365 57 48
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* Re: [PATCH 1/3] drm/i915: Ivybridge still has fences!
From: Daniel Vetter @ 2011-10-23 10:12 UTC (permalink / raw)
To: Jesse Barnes; +Cc: Daniel Vetter, intel-gfx, stable
In-Reply-To: <20111010105822.58114c0e@jbarnes-desktop>
On Mon, Oct 10, 2011 at 10:58:22AM -0700, Jesse Barnes wrote:
> On Sun, 9 Oct 2011 21:52:01 +0200
> Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> > So don't forget to restore them on resume and dump them into
> > the error state.
>
> This should probably just be >= 6 instead; I don't think we're getting
> rid of fences anytime soon.
As discussed on irc >= 6 is a bit hard to do in a switch statement ;-) Do
you want me to resend the patches using the gcc ranged switch extension
suggested by Adam Jackson (i.e. 6..UINT_MAX)? Or can you slap your r-b on
them as-is?
-Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* Re: [PATCH] drm/i915: only match on PCI_BASE_CLASS_DISPLAY
From: Daniel Vetter @ 2011-10-23 10:05 UTC (permalink / raw)
To: Keith Packard; +Cc: Daniel Vetter, intel-gfx
In-Reply-To: <4E944763.3060703@redhat.com>
Hi Keith
This patch isn't in your -next pull request. Please consider merging for
3.2.
Yours, Daniel
On Tue, Oct 11, 2011 at 09:40:51AM -0400, Adam Jackson wrote:
> On 10/11/11 4:59 AM, Daniel Vetter wrote:
> >... not DISPLAY_VGA, because we ignore the VGA subclass with our
> >class_mask.
> >
> >It confused me until Chris Wilson clued me up.
> >
> >Signed-off-by: Daniel Vetter<daniel.vetter@ffwll.ch>
>
> Reviewed-by: Adam Jackson <ajax@redhat.com>
>
> - ajax
>
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* Re: BUG: All network processes hang (brcmsmac/wpa_supplicant)
From: Arend van Spriel @ 2011-10-23 10:04 UTC (permalink / raw)
To: Nico Schottelius, Eric Dumazet, linux-wireless@vger.kernel.org
In-Reply-To: <20111022015945.GC26186@ethz.ch>
On 10/22/2011 03:59 AM, Nico Schottelius wrote:
> Hey Arend,
>
> it seems that your patch really solves this problem.
>
> I've got a new one now, though :-)
>
> After several suspend/resume cycles, my card often reconnects to my AP
> that is only several meters (2) away. If the connection is established,
> I've a very laggy connection to the AP:
>
> 64 bytes from 192.168.42.1: icmp_req=1154 ttl=64 time=10839 ms
> 64 bytes from 192.168.42.1: icmp_req=1155 ttl=64 time=9841 ms
> ...
> 64 bytes from 192.168.42.1: icmp_req=1164 ttl=64 time=2814 ms
> 64 bytes from 192.168.42.1: icmp_req=1165 ttl=64 time=16785 ms
> 64 bytes from 192.168.42.1: icmp_req=1166 ttl=64 time=20767 ms
>
> Attached are the usual suspect outputs.
> This time I'm on 2.432 Ghz.
>
> Cheers,
>
> Nico
>
Hi Nico,
I see three different AP's in this log. Could you indicate what AP you
have issues with.
[13087.196234] wlan0: RX AssocResp from 00:03:52:e3:0e:10 (capab=0x11
status=0 aid=3)
[13087.196238] wlan0: associated
[17148.068771] wlan0: RX AssocResp from 00:18:39:50:07:f3 (capab=0x421
status=0 aid=4)
[17148.068776] wlan0: associated
[19010.367351] wlan0: RX AssocResp from 00:14:6c:67:9c:32 (capab=0x611
status=0 aid=2)
[19010.367355] wlan0: associated
With the suspend/resume cycles early in the dmesg log it seems brcmsmac
gets disassoc/deauth before going to sleep. When things start to get
flaky this does not seem to happen and I see a lot of deauth reason=2 in
the log. If I am correct that would mean previousAuthNotValid. Not sure
why we see that. Will try to reproduce this tomorrow.
Gr. AvS
^ permalink raw reply
* aolm5 组 建 高 效 团 队 feoio6g0g
From: 新沂市凤鸣文化传媒发展有限公司 @ 2011-10-23 10:02 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 3126 bytes --]
[-- Attachment #2: 决△胜☆中△层.xls --]
[-- Type: application/vnd.ms-excel, Size: 34816 bytes --]
^ permalink raw reply
* Re: [PATCH] drm/i915: disable temporal dithering on the internal panel
From: Daniel Vetter @ 2011-10-23 10:03 UTC (permalink / raw)
To: keithp; +Cc: Daniel Vetter, intel-gfx
In-Reply-To: <4E9468B2.3010503@redhat.com>
Hi Keith,
This patch hasn't shown up in your -next pull request. Please consider
merging for 3.2.
Yours, Daniel
On Tue, Oct 11, 2011 at 12:02:58PM -0400, Adam Jackson wrote:
> On 10/11/11 11:27 AM, Daniel Vetter wrote:
> ><ajax> i'm getting tempted to just disable temporal
> ><mjg59> Approved.
> ><ajax> apparently it makes the screen look pulse-y which is worse
> >than the disease.
> >
> >References: http://lists.freedesktop.org/archives/intel-gfx/2011-October/012545.html
> >Tested-by: Олег Герман<oleg.german@gmail.com>
> >Cc: Adam Jackson<ajax@redhat.com>
> >Signed-off-by: Daniel Vetter<daniel.vetter@ffwll.ch>
>
> I was going to call you out for not also removing it from the GM45
> DP path, but apparently it's no longer there anyway.
>
> Might be worth wiring this up as an output property someday.
>
> Reviewed-by: Adam Jackson <ajax@redhat.com>
>
> - ajax
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH 1/1] sanbox: add linux_execve and linux_exec command
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-10-23 9:59 UTC (permalink / raw)
To: barebox
this will allow to execute a program of the host from barebox
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
arch/sandbox/mach-sandbox/include/mach/linux.h | 2 +
arch/sandbox/os/common.c | 22 +++++++++
commands/Kconfig | 4 ++
commands/Makefile | 1 +
commands/linux_exec.c | 58 ++++++++++++++++++++++++
5 files changed, 87 insertions(+), 0 deletions(-)
create mode 100644 commands/linux_exec.c
diff --git a/arch/sandbox/mach-sandbox/include/mach/linux.h b/arch/sandbox/mach-sandbox/include/mach/linux.h
index 7c2386d..5917fe9 100644
--- a/arch/sandbox/mach-sandbox/include/mach/linux.h
+++ b/arch/sandbox/mach-sandbox/include/mach/linux.h
@@ -10,6 +10,8 @@ ssize_t linux_write(int fd, const void *buf, size_t count);
off_t linux_lseek(int fildes, off_t offset);
int linux_tstc(int fd);
+int linux_execve(const char * filename, char *const argv[], char *const envp[]);
+
int barebox_register_console(char *name_template, int stdinfd, int stdoutfd);
struct linux_console_data {
diff --git a/arch/sandbox/os/common.c b/arch/sandbox/os/common.c
index 5074a06..0833959 100644
--- a/arch/sandbox/os/common.c
+++ b/arch/sandbox/os/common.c
@@ -45,6 +45,7 @@
#include <errno.h>
#include <signal.h>
#include <sys/select.h>
+#include <sys/wait.h>
/*
* ...except the ones needed to connect with barebox
*/
@@ -193,6 +194,27 @@ off_t linux_lseek(int fd, off_t offset)
return lseek(fd, offset, SEEK_SET);
}
+int linux_execve(const char * filename, char *const argv[], char *const envp[])
+{
+ pid_t pid, tpid;
+ int execve_status;
+
+ pid = fork();
+
+ if (pid == -1) {
+ perror("linux_execve");
+ return pid;
+ } else if (pid == 0) {
+ exit(execve(filename, argv, envp));
+ } else {
+ do {
+ tpid = wait(&execve_status);
+ } while(tpid != pid);
+
+ return execve_status;
+ }
+}
+
extern void start_barebox(void);
extern void mem_malloc_init(void *start, void *end);
diff --git a/commands/Kconfig b/commands/Kconfig
index 11386f9..1eae25a 100644
--- a/commands/Kconfig
+++ b/commands/Kconfig
@@ -124,6 +124,10 @@ config CMD_TIME
checking for ctrl-c, so the time command can be used with commands
which are interruptible with ctrl-c.
+config CMD_LINUX_EXEC
+ bool "linux exec"
+ depends on LINUX
+
endmenu
menu "file commands "
diff --git a/commands/Makefile b/commands/Makefile
index d50ca68..f50ace6 100644
--- a/commands/Makefile
+++ b/commands/Makefile
@@ -59,3 +59,4 @@ obj-$(CONFIG_CMD_USB) += usb.o
obj-$(CONFIG_CMD_TIME) += time.o
obj-$(CONFIG_CMD_BOOT_CONFIG) += boot_config.o
obj-$(CONFIG_CMD_BOOT_MENU) += boot_menu.o
+obj-$(CONFIG_CMD_LINUX_EXEC) += linux_exec.o
diff --git a/commands/linux_exec.c b/commands/linux_exec.c
new file mode 100644
index 0000000..e147629
--- /dev/null
+++ b/commands/linux_exec.c
@@ -0,0 +1,58 @@
+/*
+ * Copyright (c) 2011 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * 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 <common.h>
+#include <command.h>
+#include <mach/linux.h>
+
+static int do_linux_exec(struct command *cmdtp, int argc, char *argv[])
+{
+ int ret;
+ char **newargv;
+ char *newenv[] = { NULL };
+ int i, j;
+
+ if (argc < 2)
+ return 1;
+
+ newargv = xzalloc(sizeof(char*) * argc);
+
+ for (j = 0, i = 1; i < argc; i++, j++)
+ newargv[j] = argv[i];
+
+ newargv[j] = NULL;
+ ret = linux_execve(argv[1], newargv, newenv);
+
+ if (ret)
+ return 1;
+
+ return 0;
+}
+
+BAREBOX_CMD_HELP_START(linux_exec)
+BAREBOX_CMD_HELP_USAGE("linux_exec ...\n")
+BAREBOX_CMD_HELP_SHORT("Execute a command on the host\n")
+BAREBOX_CMD_HELP_END
+
+BAREBOX_CMD_START(linux_exec)
+ .cmd = do_linux_exec,
+ .usage = "Execute a command on the host",
+ BAREBOX_CMD_HELP(cmd_linux_exec_help)
+BAREBOX_CMD_END
--
1.7.7
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply related
* [PATCH 1/1] password: remove not used variable 'second'
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-10-23 9:59 UTC (permalink / raw)
To: barebox
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
common/password.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/common/password.c b/common/password.c
index ece7704..311f9cb 100644
--- a/common/password.c
+++ b/common/password.c
@@ -42,13 +42,12 @@ int password(unsigned char *passwd, size_t length, int flags, int timeout)
unsigned char *buf = passwd;
int pos = 0;
unsigned char ch;
- uint64_t start, second;
+ uint64_t start;
if (!passwd)
return -EINVAL;
start = get_time_ns();
- second = start;
do {
if (tstc()) {
--
1.7.7
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply related
* Re: [RFC] subdevice PM: .s_power() deprecation?
From: Sylwester Nawrocki @ 2011-10-23 9:53 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Sylwester Nawrocki, Sakari Ailus, Guennadi Liakhovetski,
Linux Media Mailing List, Tomasz Stanislawski
In-Reply-To: <201110231126.24905.laurent.pinchart@ideasonboard.com>
Hi Laurent,
On 10/23/2011 11:26 AM, Laurent Pinchart wrote:
> On Sunday 23 October 2011 11:01:15 Sylwester Nawrocki wrote:
>> On 10/23/2011 10:44 AM, Sakari Ailus wrote:
>>> Sylwester Nawrocki wrote:
>>>>>> 2. In some of our camera pipeline setups - "Sensor - MIPI-CSI receiver
>>>>>> - host/DMA",
>>>>>>
>>>>>> the sensor won't boot properly if all MIPI-CSI regulators aren't
>>>>>> enabled. So the MIPI-CSI receiver must always be powered on before
>>>>>> the sensor. With the subdevs doing their own magic wrt to power
>>>>>> control the situation is getting slightly out of control.
>>>>>
>>>>> How about this: CSI-2 receiver implements a few new regulators which
>>>>> the sensor driver then requests to be enabled. Would that work for
>>>>> you?
>>>>
>>>> No, I don't like that... :)
>>>>
>>>> We would have to standardize the regulator supply names, etc. Such
>>>> approach would be more difficult to align with runtime/system
>>>> suspend/resume. Also the sensor drivers should be independent on other
>>>> drivers. The MIPI-CSI receiver is more specific to the host, rather
>>>> than a sensor.
>>>>
>>>> Not all sensors need MIPI-CSI, some just use parallel video bus.
>>>
>>> The sensor drivers are responsible for the regulators they want to use,
>>> right? If they need no CSI-2 related regulators then they just ignore
>>
>> Only for the regulator supplies for their device. In this case the sensor
>> driver would have to touch MIPI-CSI device regulator supplies.
>>
>>> them as any other regulators the sensor doesn't need.
>>>
>>> The names of the regulators could come from the platform data, they're
>>> board specific anyway. I can't see another way to do this without having
>>
>> No, you don't want regulator supply names in any platform data struct.
>> The platform code binds regulator supplies to the devices, whether it is DT
>> based or not.
>
> You can still add a regulator name field to the sensor platform data, or a
> link to the regulator in the device tree, and use that in the sensor driver if
> present.
>
> I'm not telling it's a good solution, but it's technically doable.
Yes, that would be also possible.
>
>>> platform code to do this which is not quite compatible with the idea of
>>> the device tree.
>>
>> Now I just use s_power callback in our drivers and it all works well.
>
> Having the sensor driver calling the CSI-2 receiver s_power callback directly
> sounds a bit hackish to me. If we really want to call subdev operations from
> another subdev driver we'll need to specify that, as the current mode of
> operation (at least in my understanding) is that subdev operations are only
> called by host drivers.
I meant s_power() is only used by the host. Every device in the pipeline is
powered up by the host at video device open() in right order.
Maybe we could ad some kind of notifier to v4l core so the host gets notified
when any of subdevs registered to it gets it's video node opened ?
--
Regards,
Sylwester
^ permalink raw reply
* Re: [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table
From: Andreas Schwab @ 2011-10-23 9:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Linux/m68k, Greg Ungerer, Linux Kernel Development,
uClinux list
In-Reply-To: <alpine.DEB.2.00.1105052042590.17077@ayla.of.borg>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> From 5739b340b334de21c6da4f65d5194957662a6dd0 Mon Sep 17 00:00:00 2001
> From: Geert Uytterhoeven <geert@linux-m68k.org>
> Date: Thu, 5 May 2011 20:33:02 +0200
> Subject: [PATCH] m68k: unistd - Comment out definitions for unimplemented syscalls
This is not a good idea at least for the syscalls referenced by glibc.
It means that a glibc compiled against this <asm/unistd.h> will lose the
ability to call those syscalls even if the running kernel happens to
implement them.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [U-Boot] [Patch v2 6/7] powerpc/mpc8349emds: Migrate from spd_sdram to unified DDR driver
From: Wolfgang Denk @ 2011-10-23 9:53 UTC (permalink / raw)
To: u-boot
In-Reply-To: <2A6300E8-A874-49AC-84CB-BE681AF1BF90@freescale.com>
Dear Kumar Gala,
In message <2A6300E8-A874-49AC-84CB-BE681AF1BF90@freescale.com> you wrote:
>
> On Aug 26, 2011, at 1:32 PM, York Sun wrote:
>
> > Update MPC8349EMDS to use unified DDR driver instead of spd_sdram.c.
> > The unified driver can initialize data using DDR controller. No need to
> > use DMA if just to initialze for ECC.
> >
> > Signed-off-by: York Sun <yorksun@freescale.com>
> > Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> > ---
> > board/freescale/mpc8349emds/Makefile | 1 +
> > board/freescale/mpc8349emds/ddr.c | 107 +++++++++++++++++++++++++++++
> > board/freescale/mpc8349emds/mpc8349emds.c | 26 ++++---
> > include/configs/MPC8349EMDS.h | 16 ++++
> > 4 files changed, 139 insertions(+), 11 deletions(-)
> > create mode 100644 board/freescale/mpc8349emds/ddr.c
>
> applied to 85xx 'next'
Did you test it???
This patch breaks out-of-tree building of the MPC8349EMDS board:
+ MAKEALL_LOGDIR=/work/wd/tmp-ppc-LOG
+ BUILD_DIR=/work/wd/tmp-ppc
+ ./MAKEALL MPC8349EMDS
Configuring for MPC8349EMDS board...
make[1]: *** No rule to make target `/work/wd/tmp-ppc/arch/powerpc/cpu/mpc83xx/.depend.ddr-gen2', needed by `/work/wd/tmp-ppc/arch/powerpc/cpu/mpc83xx/.depend'. Stop.
make[1]: *** No rule to make target `/work/wd/tmp-ppc/arch/powerpc/cpu/mpc83xx/.depend.ddr-gen2', needed by `/work/wd/tmp-ppc/arch/powerpc/cpu/mpc83xx/.depend'. Stop.
make: *** [depend] Error 2
[Local building works.]
Note also that "make distclean" still leaves a file
arch/powerpc/cpu/mpc83xx/ddr-gen2.c
Please fix this, too.
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
Overflow on /dev/null, please empty the bit bucket.
^ permalink raw reply
* Re: git mergetool ignores configured command line
From: Junio C Hamano @ 2011-10-23 9:52 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Alexander Vladimirov, git
In-Reply-To: <m21uu4hzmq.fsf@linux-m68k.org>
Andreas Schwab <schwab@linux-m68k.org> writes:
> diffuse is already a predefined merge tool, so mergetool.diffuse.cmd is
> ignored. Try using a different name.
I wonder if we can improve this, though.
It is nice that we give canned definition of argument order to so many
obscure tools, but instead of ignoring mergetool.<tool>.cmd when the user
told us to use <tool>, couldn't we simply ignore what we have internally
as canned definition?
Even if such a change were too intrusive (I didn't check), could we have
a decency to at least warn that we are ignoring the configuration?
^ permalink raw reply
* Re: Bisected: Massive memory leak in dm-snapshot in 3.1 development introduced
From: Linus Torvalds @ 2011-10-23 9:52 UTC (permalink / raw)
To: Alasdair G Kergon; +Cc: Michael Leun, LKML, dm-devel, Mikulas Patocka
In-Reply-To: <20111023112140.37fd8b3d@xenia.leun.net>
Making sure that Alasdair sees this too (hopefully he picked up on it
from dm-devel, but best send things directly too)
Mikulas, Alasdair? I see the mempool_free() for the "master job", what
about everything else? Does the dm_kcopyd_prepare_callback() perhaps
need to do a
job->master_job = job;
or similar?
Linus
On Sun, Oct 23, 2011 at 12:21 PM, Michael Leun <ml@newton.leun.net> wrote:
> Hi,
>
> How to reproduce:
>
> lvcreate -L30G -n testsnap vg1 # of course substitute VG as appropriate
> dd if=/dev/zero of=/dev/vg1/testsnap bs=2M # to make things clear
> lvcreate -L15G -s /dev/vg1/test -n testsnap
> dd if=/dev/zero of=/dev/vg1/testsnap bs=2M &
> watch free
>
> I noticed roughly 1GB memory vanishing from free / -/+ buffers/cache
> per 2GB copied.
>
> Bisecting yielded a6e50b409d3f9e0833e69c3c9cca822e8fa4adbb, reverting
> that from git master cures the memory leak
>
> --
> MfG,
>
> Michael Leun
>
>
^ permalink raw reply
* Re: [PATCH 00/28 v6] m68k: Convert to genirq
From: Geert Uytterhoeven @ 2011-10-23 9:49 UTC (permalink / raw)
To: linux-m68k, Greg Ungerer, Thomas Gleixner; +Cc: linux-kernel, netdev
In-Reply-To: <CAMuHMdWOhKcoDoyTnKJzruZ=gpV5uKNFpXnGCkrac7oEkCihJw@mail.gmail.com>
On Thu, Oct 20, 2011 at 14:18, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Sun, Sep 11, 2011 at 13:59, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> This patch series converts the m68k/mmu (nommu was converted before)
>> architecture to the generic hardirq framework.
>>
>> - [01/28] genirq: Add missing "else" in irq_shutdown()
>> - [02/28] ide-{cd,floppy,tape}: Do not include <linux/irq.>
>> - [03/28] keyboard: Do not include <linux/irq.>
>> - [04/28] m68k/irq: Rename irq_controller to irq_chip
>> - [05/28] m68k/irq: Kill irq_node_t typedef, always use struct irq_node
>> - [06/28] m68k/irq: Rename irq_node to irq_data
>> - [07/28] m68k/irq: Switch irq_chip methods to "struct irq_data *data"
>> - [08/28] m68k/irq: Rename setup_irq() to m68k_setup_irq() and make it static
>> - [09/28] m68k/irq: Extract irq_set_chip()
>> - [10/28] m68k/irq: Add m68k_setup_irq_controller()
>> - [11/28] m68k/irq: Rename {,__}m68k_handle_int()
>> - [12/28] m68k/irq: Remove obsolete IRQ_FLG_* definitions and users
>> - [13/28] m68k/irq: Add genirq support
>> - [14/28] m68k/atari: Convert Atari to genirq
>> - [15/28] m68k/atari: Remove code and comments about different irq types
>> - [16/28] m68k/amiga: Refactor amiints.c
>> - [17/28] m68k/amiga: Convert Amiga to genirq
>> - [18/28] m68k/amiga: Optimize interrupts using chain handlers
>> - [19/28] m68k/mac: Convert Mac to genirq
>> - [20/28] m68k/mac: Optimize interrupts using chain handlers
>> - [21/28] m68k/hp300: Convert HP9000/300 and HP9000/400 to genirq
>> - [22/28] m68k/vme: Convert VME to genirq
>> - [23/28] m68k/apollo: Convert Apollo to genirq
>> - [24/28] m68k/sun3: Use the kstat_irqs_cpu() wrapper
>> - [25/28] m68k/sun3: Convert Sun3/3x to genirq
>> - [26/28] m68k/q40: Convert Q40/Q60 to genirq
>> - [27/28] m68k/irq: Remove obsolete m68k irq framework
>> - [28/28] m68k/irq: Remove obsolete support for user vector interrupt fixups
>>
>> Overview:
>> - [01] is a fix for the core genirq code,
>
> This went into v3.1-rc6.
>
>> - [02-03] are fixes to avoid compile problems later in the conversion
>> process,
>
> The keyboard path went into the tty -next tree.
> The IDE one is still pending (I've just resent it).
The IDE one got acked in the mean time.
>> I will update my m68k-genirq branch as soon as master.kernel.org is available
>> again.
>
> Updated, on top of m68k master (which is at v3.1-rc10 now).
> http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/m68k-genirq
>
> If noone objects, I'd like to add this to the m68k master and for-3.2 branches.
I added it to m68k master.
As there were several merge conflicts with current -next
(arch/m68k/kernel/Makefile_mm
due to the mmu/nommu merge, and drivers/net/macsonic.c in [12/28] due
to the network
driver reshuffling dance), I did not add it to for-3.2 and for-next,
but to for-3.3.
Depending on Stephen's return during or after the merge window, and
the merge timing
of the m68knommu and netdev trees, I may stil try to sneak it in 3.2, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 00/28 v6] m68k: Convert to genirq
From: Geert Uytterhoeven @ 2011-10-23 9:49 UTC (permalink / raw)
To: linux-m68k, Greg Ungerer, Thomas Gleixner; +Cc: linux-kernel, netdev
In-Reply-To: <CAMuHMdWOhKcoDoyTnKJzruZ=gpV5uKNFpXnGCkrac7oEkCihJw@mail.gmail.com>
On Thu, Oct 20, 2011 at 14:18, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Sun, Sep 11, 2011 at 13:59, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> This patch series converts the m68k/mmu (nommu was converted before)
>> architecture to the generic hardirq framework.
>>
>> - [01/28] genirq: Add missing "else" in irq_shutdown()
>> - [02/28] ide-{cd,floppy,tape}: Do not include <linux/irq.>
>> - [03/28] keyboard: Do not include <linux/irq.>
>> - [04/28] m68k/irq: Rename irq_controller to irq_chip
>> - [05/28] m68k/irq: Kill irq_node_t typedef, always use struct irq_node
>> - [06/28] m68k/irq: Rename irq_node to irq_data
>> - [07/28] m68k/irq: Switch irq_chip methods to "struct irq_data *data"
>> - [08/28] m68k/irq: Rename setup_irq() to m68k_setup_irq() and make it static
>> - [09/28] m68k/irq: Extract irq_set_chip()
>> - [10/28] m68k/irq: Add m68k_setup_irq_controller()
>> - [11/28] m68k/irq: Rename {,__}m68k_handle_int()
>> - [12/28] m68k/irq: Remove obsolete IRQ_FLG_* definitions and users
>> - [13/28] m68k/irq: Add genirq support
>> - [14/28] m68k/atari: Convert Atari to genirq
>> - [15/28] m68k/atari: Remove code and comments about different irq types
>> - [16/28] m68k/amiga: Refactor amiints.c
>> - [17/28] m68k/amiga: Convert Amiga to genirq
>> - [18/28] m68k/amiga: Optimize interrupts using chain handlers
>> - [19/28] m68k/mac: Convert Mac to genirq
>> - [20/28] m68k/mac: Optimize interrupts using chain handlers
>> - [21/28] m68k/hp300: Convert HP9000/300 and HP9000/400 to genirq
>> - [22/28] m68k/vme: Convert VME to genirq
>> - [23/28] m68k/apollo: Convert Apollo to genirq
>> - [24/28] m68k/sun3: Use the kstat_irqs_cpu() wrapper
>> - [25/28] m68k/sun3: Convert Sun3/3x to genirq
>> - [26/28] m68k/q40: Convert Q40/Q60 to genirq
>> - [27/28] m68k/irq: Remove obsolete m68k irq framework
>> - [28/28] m68k/irq: Remove obsolete support for user vector interrupt fixups
>>
>> Overview:
>> - [01] is a fix for the core genirq code,
>
> This went into v3.1-rc6.
>
>> - [02-03] are fixes to avoid compile problems later in the conversion
>> process,
>
> The keyboard path went into the tty -next tree.
> The IDE one is still pending (I've just resent it).
The IDE one got acked in the mean time.
>> I will update my m68k-genirq branch as soon as master.kernel.org is available
>> again.
>
> Updated, on top of m68k master (which is at v3.1-rc10 now).
> http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/m68k-genirq
>
> If noone objects, I'd like to add this to the m68k master and for-3.2 branches.
I added it to m68k master.
As there were several merge conflicts with current -next
(arch/m68k/kernel/Makefile_mm
due to the mmu/nommu merge, and drivers/net/macsonic.c in [12/28] due
to the network
driver reshuffling dance), I did not add it to for-3.2 and for-next,
but to for-3.3.
Depending on Stephen's return during or after the merge window, and
the merge timing
of the m68knommu and netdev trees, I may stil try to sneak it in 3.2, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 00/28 v6] m68k: Convert to genirq
From: Geert Uytterhoeven @ 2011-10-23 9:49 UTC (permalink / raw)
To: linux-m68k, Greg Ungerer, Thomas Gleixner; +Cc: linux-kernel, netdev
In-Reply-To: <CAMuHMdWOhKcoDoyTnKJzruZ=gpV5uKNFpXnGCkrac7oEkCihJw@mail.gmail.com>
On Thu, Oct 20, 2011 at 14:18, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Sun, Sep 11, 2011 at 13:59, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> This patch series converts the m68k/mmu (nommu was converted before)
>> architecture to the generic hardirq framework.
>>
>> - [01/28] genirq: Add missing "else" in irq_shutdown()
>> - [02/28] ide-{cd,floppy,tape}: Do not include <linux/irq.>
>> - [03/28] keyboard: Do not include <linux/irq.>
>> - [04/28] m68k/irq: Rename irq_controller to irq_chip
>> - [05/28] m68k/irq: Kill irq_node_t typedef, always use struct irq_node
>> - [06/28] m68k/irq: Rename irq_node to irq_data
>> - [07/28] m68k/irq: Switch irq_chip methods to "struct irq_data *data"
>> - [08/28] m68k/irq: Rename setup_irq() to m68k_setup_irq() and make it static
>> - [09/28] m68k/irq: Extract irq_set_chip()
>> - [10/28] m68k/irq: Add m68k_setup_irq_controller()
>> - [11/28] m68k/irq: Rename {,__}m68k_handle_int()
>> - [12/28] m68k/irq: Remove obsolete IRQ_FLG_* definitions and users
>> - [13/28] m68k/irq: Add genirq support
>> - [14/28] m68k/atari: Convert Atari to genirq
>> - [15/28] m68k/atari: Remove code and comments about different irq types
>> - [16/28] m68k/amiga: Refactor amiints.c
>> - [17/28] m68k/amiga: Convert Amiga to genirq
>> - [18/28] m68k/amiga: Optimize interrupts using chain handlers
>> - [19/28] m68k/mac: Convert Mac to genirq
>> - [20/28] m68k/mac: Optimize interrupts using chain handlers
>> - [21/28] m68k/hp300: Convert HP9000/300 and HP9000/400 to genirq
>> - [22/28] m68k/vme: Convert VME to genirq
>> - [23/28] m68k/apollo: Convert Apollo to genirq
>> - [24/28] m68k/sun3: Use the kstat_irqs_cpu() wrapper
>> - [25/28] m68k/sun3: Convert Sun3/3x to genirq
>> - [26/28] m68k/q40: Convert Q40/Q60 to genirq
>> - [27/28] m68k/irq: Remove obsolete m68k irq framework
>> - [28/28] m68k/irq: Remove obsolete support for user vector interrupt fixups
>>
>> Overview:
>> - [01] is a fix for the core genirq code,
>
> This went into v3.1-rc6.
>
>> - [02-03] are fixes to avoid compile problems later in the conversion
>> process,
>
> The keyboard path went into the tty -next tree.
> The IDE one is still pending (I've just resent it).
The IDE one got acked in the mean time.
>> I will update my m68k-genirq branch as soon as master.kernel.org is available
>> again.
>
> Updated, on top of m68k master (which is at v3.1-rc10 now).
> http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/m68k-genirq
>
> If noone objects, I'd like to add this to the m68k master and for-3.2 branches.
I added it to m68k master.
As there were several merge conflicts with current -next
(arch/m68k/kernel/Makefile_mm
due to the mmu/nommu merge, and drivers/net/macsonic.c in [12/28] due
to the network
driver reshuffling dance), I did not add it to for-3.2 and for-next,
but to for-3.3.
Depending on Stephen's return during or after the merge window, and
the merge timing
of the m68knommu and netdev trees, I may stil try to sneak it in 3.2, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [RFC][PATCH] uncompress.h cleanup and DT support
From: Russell King - ARM Linux @ 2011-10-23 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111023094309.GM15299@pengutronix.de>
On Sun, Oct 23, 2011 at 11:43:09AM +0200, Uwe Kleine-K?nig wrote:
> On Sun, Oct 23, 2011 at 10:20:59AM +0100, Russell King - ARM Linux wrote:
> > On Sun, Oct 23, 2011 at 11:12:50AM +0200, Zoltan Devai wrote:
> > > 2011/10/23 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> > > > On Sun, Oct 23, 2011 at 10:18:29AM +0200, Zoltan Devai wrote:
> > > >> Plase consider all this as RFC, it's mostly not even compile-tested.
> > > >> If you think it's worth to follow-up, I'm happy to do it.
> > > >
> > > > Is the patch available?
> > > git://github.com/zdevai/linux.git uncompress-h
> >
> > I'd rather not pull your tree just to look at the patch. Is it
> > available somewhere else?
> It's not hard to look at it and no need to pull, just do:
>
> git fetch git://github.com/zdevai/linux.git uncompress-h
> git log -p ..FETCH_HEAD
.1 We do reviews in patch form on mailing lists, not from commits inside
git trees.
.2 I don't even want to pull the objects into my tree - that's a waste of
bandwidth just to _read_ the patch, and risks pulling in a lot more
depending on the parents of the commit.
So, please stick to patch form. If it's too large for the mailing list,
please split the patch up into a logical sequence of steps as individual
patches. Only then provide a gitweb URL if that's not possible.
If the diffstat at the start of this thread reflects a single patch then
it's doing too much as one change.
^ permalink raw reply
* Re: [PATCH 00/22] Refactor to accept NUL in commit messages
From: Junio C Hamano @ 2011-10-23 9:46 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, peff, Ævar Arnfjörð
In-Reply-To: <CACsJy8CA2cqJqt7cUN1CdnOb3=qE6B2XTd1oQKZ7osVz09kSGg@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Sun, Oct 23, 2011 at 4:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> The low level object format of our commit is textual header fields, each
>> of which is terminated with a LF, followed by a LF to mark the end of
>> header fields, and then opaque payload that can contain any bytes. It does
>> not forbid a non-Git application to reuse the object store infrastructure
>> to store ASN.1 binary goo there, and the low level interface we give such
>> as cat-file is a perfectly valid way to inspect such a "commit" object.
>
> cat-file is fine, commit-tree (or any commands that call
> commit_tree()) cuts at NUL though.
> I wonder how git processes commit messages in utf-16.
That is exactly what I am saying.
Perhaps you didn't either read or understand what you omitted from your
quoting; otherwise you even wouldn't have brought up utf-16.
Let me requote that part for you.
> But when it comes to "Git" Porcelains (e.g. the log family of commands),
> we do assume people do not store random binary byte sequences in commits,
> and we do take advantage of that assumption by splitting each "line" at
> LF, indenting them with 4 spaces, etc. In other words, a commit log in the
> Git context _is_ pretty much text and not arbitrary byte sequence.
Think what would cutting at a byte whose value is 012 and adding four
bytes whose values are 040 to each of "lines" that formed with such
cutting do to UTF-16 goo, even if it does not contain any NUL byte. As far
as Git Porcelains are concerned, it is no different from random binary
byte sequences.
^ 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.