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:
>
&g
Acked-by: Hirokazu Takata tak...@linux-m32r.org
Al, many thanks for your great job.
P.S. I'm struggling to reconstruct and repair my m32r test environment...
-- Takata
From: Al Viro v...@zeniv.linux.org.uk
Subject: Re: [update] Re: new execve/kernel_thread design
Date: Fri, 07 Dec 2012 22:23
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
>
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
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
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
on
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
On Sun, Nov 18, 2012 at 08:45:43AM -1000, Linus Torvalds wrote:
On Sat, Nov 17, 2012 at 7:45 PM, Al Viro v...@zeniv.linux.org.uk 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
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
On Sat, Nov 17, 2012 at 7:45 PM, Al Viro v...@zeniv.linux.org.uk 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
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
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 #include
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
2012/11/15 Al Viro v...@zeniv.linux.org.uk:
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.
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
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
Hi Al,
2012/10/17 Al Viro v...@zeniv.linux.org.uk:
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
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_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
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?
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
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
On Fri, 26 Oct 2012 19:31:07 +0100
Al Viro v...@zeniv.linux.org.uk 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
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 relevant
On Mon, 29 Oct 2012 13:25:21 +
Al Viro v...@zeniv.linux.org.uk 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
On Mon, Oct 29, 2012 at 03:38:23PM +0100, Martin Schwidefsky wrote:
On Mon, 29 Oct 2012 13:25:21 +
Al Viro v...@zeniv.linux.org.uk 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
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 -
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
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
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 - powerpc
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
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 it
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
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
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
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
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
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 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 reports
On Fri, Oct 19, 2012 at 10:30 AM, Al Viro v...@zeniv.linux.org.uk 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
On Fri, Oct 19, 2012 at 11:01:53AM -0700, Tony Luck wrote:
On Fri, Oct 19, 2012 at 10:30 AM, Al Viro v...@zeniv.linux.org.uk wrote:
IIRC, the lack of comments on function with unusual calling conventions was
the last remaining issue...
Stylistically other asm functions have huge block
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 -
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
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
On 17 October 2012 00:35, Al Viro v...@zeniv.linux.org.uk 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
2012/10/17 Jonas Bonn jo...@southpole.se:
On 17 October 2012 00:35, Al Viro v...@zeniv.linux.org.uk 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
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 the
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 - future
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,
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,
[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...]
Below is an attempt to describe how kernel threads work now. I'm
going to put a cleaned up variant into
[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...]
Below is an attempt to describe how kernel threads work now. I'm
going to put a cleaned up variant into
On Wed, Oct 17, 2012 at 2:35 AM, Al Viro v...@zeniv.linux.org.uk 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:
On Wed, Oct 17, 2012 at 09:32:34AM +0400, Max Filippov wrote:
On Wed, Oct 17, 2012 at 2:35 AM, Al Viro v...@zeniv.linux.org.uk 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
56 matches
Mail list logo
