Acked-by: Hirokazu Takata
Al, many thanks for your great job.
P.S. I'm struggling to reconstruct and repair my m32r test environment...
-- Takata
From: Al Viro
Subject: Re: [update] Re: new execve/kernel_thread design
Date: Fri, 07 Dec 2012 22:23:58 +
> Current situation:
>
On 12/7/2012 5:23 PM, Al Viro wrote:
> Current situation:
>
> * most of the architectures are OK - alpha arm arm64 c6x frv hexagon ia64 m68k
> microblaze mips openrisc parisc sparc s390 tile um unicore32 x86 xtensa
>
> * powerpc *still* awaits an ACK from maintainers; no reports of any breakage
> o
Current situation:
* most of the architectures are OK - alpha arm arm64 c6x frv hexagon ia64 m68k
microblaze mips openrisc parisc sparc s390 tile um unicore32 x86 xtensa
* powerpc *still* awaits an ACK from maintainers; no reports of any breakage
on linux-next and seems to be doing fine on my tes
On Sun, Nov 18, 2012 at 08:45:43AM -1000, Linus Torvalds wrote:
> On Sat, Nov 17, 2012 at 7:45 PM, Al Viro wrote:
> >
> > Linus, do you have any objections to the above? FWIW, I've a tentative
> > patchset in that direction (most of it from the last cycle); right now
> > it + stuff currently in s
On Sat, Nov 17, 2012 at 7:45 PM, Al Viro wrote:
>
> Linus, do you have any objections to the above? FWIW, I've a tentative
> patchset in that direction (most of it from the last cycle); right now
> it + stuff currently in signal.git#for-next is at -3.4KLoC and I hadn't
> dealt with the biarch sid
On Fri, Nov 16, 2012 at 08:59:25AM +0100, Michal Simek wrote:
> Do you have set of tests which should run it?
>
>
> > 2) your definition of current_pt_regs() is an exact copy of on in
> > include/linux/ptrace.h; why is "microblaze: Define current_pt_regs"
> > needed at all? IOW, I'd rather added
2012/11/15 Al Viro :
> On Thu, Nov 15, 2012 at 05:41:16PM +0100, Michal Simek wrote:
>> Here is the branch based on rc5 (information below)
>> and here is giweb.
>> http://developer.petalogix.com/git/gitweb.cgi?p=linux-2.6-microblaze.git;a=shortlog;h=refs/heads/viro/arch-microblaze-rc5
>>
>> I have
On Thu, Nov 15, 2012 at 05:41:16PM +0100, Michal Simek wrote:
> Here is the branch based on rc5 (information below)
> and here is giweb.
> http://developer.petalogix.com/git/gitweb.cgi?p=linux-2.6-microblaze.git;a=shortlog;h=refs/heads/viro/arch-microblaze-rc5
>
> I have also looked at your sys_fo
Hi Al,
2012/10/17 Al Viro :
> On Wed, Oct 17, 2012 at 05:07:03PM +0100, Al Viro wrote:
>> What happens during boot is this:
>> * init_task (not to be confused with init) is used as current during
>> infrastructure initializations. Once everything needed for scheduler and
>> for working fork
On Mon, Oct 29, 2012 at 03:38:23PM +0100, Martin Schwidefsky wrote:
> On Mon, 29 Oct 2012 13:25:21 +
> Al Viro wrote:
>
> > On Mon, Oct 29, 2012 at 08:53:39AM +0100, Martin Schwidefsky wrote:
> >
> > > Oops, sorry. I tested this weeks ago but it seems I never wrote a mail to
> > > indicate s
On Mon, 29 Oct 2012 13:25:21 +
Al Viro wrote:
> On Mon, Oct 29, 2012 at 08:53:39AM +0100, Martin Schwidefsky wrote:
>
> > Oops, sorry. I tested this weeks ago but it seems I never wrote a mail to
> > indicate success. The current git kernel works just fine.
>
> "Current git" being what? Li
On Mon, Oct 29, 2012 at 08:53:39AM +0100, Martin Schwidefsky wrote:
> Oops, sorry. I tested this weeks ago but it seems I never wrote a mail to
> indicate success. The current git kernel works just fine.
"Current git" being what? Linus' tree? linux-next? signal.git#arch-s390?
FWIW, the relevan
On Fri, 26 Oct 2012 19:31:07 +0100
Al Viro wrote:
> The situation got much better by now. More than a half of
> architectures are done - alpha arm arm64 c6x hexagon ia64 m68k mips openrisc
> parisc sparc tile um unicore32 and x86.
>
> Two more avait ACKs from maintainers - powerpc a
On Fri, Oct 26, 2012 at 07:31:07PM +0100, Al Viro wrote:
> The situation got much better by now. More than a half of
> architectures are done - alpha arm arm64 c6x hexagon ia64 m68k mips openrisc
> parisc sparc tile um unicore32 and x86.
>
> Two more avait ACKs from maintainers - powe
The situation got much better by now. More than a half of
architectures are done - alpha arm arm64 c6x hexagon ia64 m68k mips openrisc
parisc sparc tile um unicore32 and x86.
Two more avait ACKs from maintainers - powerpc and s390. Should work,
AFAICS.
xtensa - Max was g
On Tue, Oct 16, 2012 at 11:35:08PM +0100, Al Viro wrote:
> Maintainers are Cc'd. My (very, _very_ tentative) patchsets are in
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal arch-$ARCH
>
> Nearly in the same state: ia64. The only difference is that I've tested
> it under ski(1) and i
On Fri, Oct 19, 2012 at 11:01:53AM -0700, Tony Luck wrote:
> On Fri, Oct 19, 2012 at 10:30 AM, Al Viro wrote:
> > IIRC, the lack of comments on function with unusual calling conventions was
> > the last remaining issue...
>
> Stylistically other asm functions have huge block header
> comments det
On Fri, Oct 19, 2012 at 10:30 AM, Al Viro wrote:
> IIRC, the lack of comments on function with unusual calling conventions was
> the last remaining issue...
Stylistically other asm functions have huge block header
comments detailing register usage. But typically those
are way more complex. I thin
On Fri, Oct 19, 2012 at 05:16:50PM +, Luck, Tony wrote:
> > Surprisingly enough, ia64 one seems to work on actual hardware; I have sent
> > Tony an incremental patch cleaning copy_thread() up, waiting for results of
> > testing that on SMP box.
>
> Tiny bit faster than plain 3.7-rc1. lmbench3
> Surprisingly enough, ia64 one seems to work on actual hardware; I have sent
> Tony an incremental patch cleaning copy_thread() up, waiting for results of
> testing that on SMP box.
Tiny bit faster than plain 3.7-rc1. lmbench3 reports fork+execve test at between
558 to 567 usec with the new code,
On Tue, Oct 16, 2012 at 11:35:08PM +0100, Al Viro wrote:
> 1. Basic rules for process lifetime.
> Except for the initial process (init_task, eventual idle thread on the boot
> CPU) all processes are created by do_fork(). There are three classes of
> those: kernel threads, userland processes
On Wed, Oct 17, 2012 at 05:07:03PM +0100, Al Viro wrote:
> What happens during boot is this:
> * init_task (not to be confused with init) is used as current during
> infrastructure initializations. Once everything needed for scheduler and
> for working fork is set, we spawn two threads - fut
On Wed, Oct 17, 2012 at 04:27:06PM +0200, Michal Simek wrote:
> In the patch above there is directly used current_pt_regs() function
> which works good for newly created threads
> when pt_regs are exactly in current_pt_regs() position but not for
> pt_regs which are saved on the stack
> which is t
2012/10/17 Jonas Bonn :
> On 17 October 2012 00:35, Al Viro wrote:
>>
>> Not even a tentative patchset: hexagon, openrisc, tile, xtensa.
>>
>
> I did most of the OpenRISC conversion last weekend... the
> kernel_thread bits work fine but I end up with the init thread dying
> with what I've got now
On 17 October 2012 00:35, Al Viro wrote:
>
> Not even a tentative patchset: hexagon, openrisc, tile, xtensa.
>
I did most of the OpenRISC conversion last weekend... the
kernel_thread bits work fine but I end up with the init thread dying
with what I've got now for kernel_execve. Once I've got th
On Wed, Oct 17, 2012 at 09:32:34AM +0400, Max Filippov wrote:
> On Wed, Oct 17, 2012 at 2:35 AM, Al Viro wrote:
> > [apologies for enormous Cc; I've talked to some of you in private mail
> > and after being politely asked to explain WTF was all that thing for
> > and how was it supposed to work, w
On Wed, Oct 17, 2012 at 2:35 AM, Al Viro wrote:
> [apologies for enormous Cc; I've talked to some of you in private mail
> and after being politely asked to explain WTF was all that thing for
> and how was it supposed to work, well...]
[...]
> Not even a tentative patchset: hexagon, openrisc, ti
27 matches
Mail list logo
