On Sat, 5 Jul 2014, Jiri Kosina wrote:
> > > The same holds for the kernel threads -- until all (or most of) the
> > > kthreads are converted to workqueues, the obivous choice, that should
> > > cover most of the use-cases, has been made.
> >
> > But, this is different.
>
> Quite frankly, I
On Sat, Jul 05, 2014 at 11:06:28PM +0200, Jiri Kosina wrote:
> On Sat, 5 Jul 2014, Tejun Heo wrote:
>
> > It'd be awesome if people who are working on the features can talk to
> > each other and see whether things can be combined.
>
> Oh, I absolutely agree; trust me, we are trying to get as much
On Sat, 5 Jul 2014, Tejun Heo wrote:
> It'd be awesome if people who are working on the features can talk to
> each other and see whether things can be combined.
Oh, I absolutely agree; trust me, we are trying to get as much discussion
going on as possible :) I proposed it as a Kernel Summit top
Hello,
On Sat, Jul 05, 2014 at 10:49:18PM +0200, Jiri Kosina wrote:
> Quite frankly, I have to say that I don't personally see *that* big
> difference. In both cases we are making assumptions about semantics, and
> are trying to get "as close as possible" to the point in time where the
> set of
On Sat, 5 Jul 2014, Tejun Heo wrote:
> > What we need is to have a defined point in execution where we can draw a
> > line between "old" and "new" universes. For processess that are crossing
> > the userspace/kernelspace boundary, the obvious choice, that covers most
> > of the use-cases, has b
Hello,
On Sat, Jul 05, 2014 at 10:04:52PM +0200, Jiri Kosina wrote:
> What we need is to have a defined point in execution where we can draw a
> line between "old" and "new" universes. For processess that are crossing
> the userspace/kernelspace boundary, the obvious choice, that covers most
>
On Wed, 2 Jul 2014, Tejun Heo wrote:
> > static inline bool try_to_freeze(void)
> > {
> > + kgr_task_safe(current);
> > +
> > if (!(current->flags & PF_NOFREEZE))
> > debug_check_no_locks_held();
> > return try_to_freeze_unsafe();
>
> Heh, I'm totally confu
Hi Jiri,
On Wed, 02 Jul 2014 14:04:38 +0200 Jiri Slaby wrote:
>
> may I ask you to add the kGraft tree to -next?
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jirislaby/kgraft.git#kgraft
Given the ongoing discussion, I think this needs to wait ...
--
Cheers,
Stephen Rothwell
On Wed, Jul 02, 2014 at 08:30:02AM -0400, Tejun Heo wrote:
> Hello,
>
> On Wed, Jul 02, 2014 at 02:04:38PM +0200, Jiri Slaby wrote:
> > On 06/25/2014 01:05 PM, Jiri Slaby wrote:
> ...
> > > https://git.kernel.org/cgit/linux/kernel/git/jirislaby/kgraft.git/log/?h=kgraft
> >
> > Stephen,
> >
> > m
Hello,
On Wed, Jul 02, 2014 at 03:01:16PM +0200, Jiri Kosina wrote:
> static inline bool try_to_freeze(void)
> {
> + kgr_task_safe(current);
> +
> if (!(current->flags & PF_NOFREEZE))
> debug_check_no_locks_held();
> return try_to_freeze_unsafe();
Heh, I'm
On Wed, 2 Jul 2014, One Thousand Gnomes wrote:
> > > > https://git.kernel.org/cgit/linux/kernel/git/jirislaby/kgraft.git/log/?h=kgraft
> > >
> > > Stephen,
> > >
> > > may I ask you to add the kGraft tree to -next?
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/jirislaby/kgraft.git#k
On Wed, 2 Jul 2014 08:30:02 -0400
Tejun Heo wrote:
> Hello,
>
> On Wed, Jul 02, 2014 at 02:04:38PM +0200, Jiri Slaby wrote:
> > On 06/25/2014 01:05 PM, Jiri Slaby wrote:
> ...
> > > https://git.kernel.org/cgit/linux/kernel/git/jirislaby/kgraft.git/log/?h=kgraft
> >
> > Stephen,
> >
> > may I a
On Wed, 2 Jul 2014 08:30:02 -0400
Tejun Heo wrote:
> Hello,
>
> On Wed, Jul 02, 2014 at 02:04:38PM +0200, Jiri Slaby wrote:
> > On 06/25/2014 01:05 PM, Jiri Slaby wrote:
> ...
> > > https://git.kernel.org/cgit/linux/kernel/git/jirislaby/kgraft.git/log/?h=kgraft
> >
> > Stephen,
> >
> > may I a
Hello,
On Wed, Jul 02, 2014 at 02:04:38PM +0200, Jiri Slaby wrote:
> On 06/25/2014 01:05 PM, Jiri Slaby wrote:
...
> > https://git.kernel.org/cgit/linux/kernel/git/jirislaby/kgraft.git/log/?h=kgraft
>
> Stephen,
>
> may I ask you to add the kGraft tree to -next?
>
> git://git.kernel.org/pub/scm
On 06/25/2014 01:05 PM, Jiri Slaby wrote:
> Hi,
>
> this is a repost of the second round of RFC on kGraft, the linux
> kernel online patching developed at SUSE. This repost only widened the
> target audience for broader review, no code change happened.
>
> Please speak up now (or be silent till t
15 matches
Mail list logo
