search for: get_maintainers

...exclusions are tested before file matches. Can be useful for excluding a specific subdirectory, for instance: diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl index ce4cc83..27dc5cb 100755 --- a/scripts/get_maintainer.pl +++ b/scripts/get_maintainer.pl @@ -611,7 +611,7 @@ sub get_maintainers { $hash{$tvi} = $value_pd; } } - } elsif ($type eq 'K') { + } elsif ($type eq 'K' || $type eq 'N') { if ($file =~ m/$value/x) { $hash{$tvi} = 0; } -- 1.7.10.4

...exclusions are tested before file matches. Can be useful for excluding a specific subdirectory, for instance: diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl index ce4cc83..27dc5cb 100755 --- a/scripts/get_maintainer.pl +++ b/scripts/get_maintainer.pl @@ -611,7 +611,7 @@ sub get_maintainers { $hash{$tvi} = $value_pd; } } - } elsif ($type eq 'K') { + } elsif ($type eq 'K' || $type eq 'N') { if ($file =~ m/$value/x) { $hash{$tvi} = 0; } -- 1.7.10.4

...ed -K: (?i)[^a-z]tegra +N: [^a-z]tegra TEHUTI ETHERNET DRIVER M: Andy Gospodarek <andy at greyhouse.net> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl index ce4cc83..5e4fb14 100755 --- a/scripts/get_maintainer.pl +++ b/scripts/get_maintainer.pl @@ -611,7 +611,7 @@ sub get_maintainers { $hash{$tvi} = $value_pd; } } - } elsif ($type eq 'K') { + } elsif ($type eq 'N') { if ($file =~ m/$value/x) { $hash{$tvi} = 0; } -- 1.7.10.4

Hey, This change adds an entry to the maintainers file to explicitly state that any changes to vmware.c should be sent to the authors of the file as well. If you are thinking why do this now, off late we have seen quite a few changes that touched the "arch/x86/kernel/cpu/vmware.c" file but were not directed to me, someone else made me aware of those changes. It could be that my use of

Hey, This change adds an entry to the maintainers file to explicitly state that any changes to vmware.c should be sent to the authors of the file as well. If you are thinking why do this now, off late we have seen quite a few changes that touched the "arch/x86/kernel/cpu/vmware.c" file but were not directed to me, someone else made me aware of those changes. It could be that my use of

With the numbers of patches flying around it can be a bit hard for a maintainer to spot patches which (s)he is expected to comment on / deal with, especially now that we have a larger number of maintainers of varying subsystems etc. I think it might be time to start asking patch submitters to CC the maintainers of the code they are touching, based on the MAINTAINERS file. If people (specifically

Dropping Tegra ML, it's not the place where Nouveau mails should go. Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best. Am Montag, den 04.03.2013, 22:16 +0100 schrieb Borislav Petkov: > New -rc1, so let the stabilization games begin. > > I see the following on rc1, let me know if you need more info. > > > [ 0.633617]

I think I might be mad to include that many mailing lists in this patchset... As I explained in [PATCH 1/5], fstests covers more and more fs testing thing, so we always get help from fs specific mailing list, due to they learn about their features and bugs more. Besides that, some folks help to review patches (relevant with them) more often. So I'd like to bring in the similar way of

On Wed, 2013-09-04 at 14:23 +0530, Alok Kataria wrote: > Hey, > > This change adds an entry to the maintainers file to explicitly state > that any changes to vmware.c should be sent to the authors of the file > as well. It never hurts to add MAINTAINER entries. > If you are thinking why do this now, off late we have seen quite a few > changes that touched the

On Tue, Dec 01, 2015 at 06:21:06PM -0800, Sinclair Yeh wrote: > On Tue, Dec 01, 2015 at 04:04:08PM -0800, Greg Kroah-Hartman wrote: > > On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote: > > > Hi, > > > > > > On Tue, Dec 01, 2015 at 02:45:27PM -0800, Dmitry Torokhov wrote: > > > > On Tue, Dec 1, 2015 at 2:32 PM, Sinclair Yeh <syeh at

On Tue, Dec 01, 2015 at 06:21:06PM -0800, Sinclair Yeh wrote: > On Tue, Dec 01, 2015 at 04:04:08PM -0800, Greg Kroah-Hartman wrote: > > On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote: > > > Hi, > > > > > > On Tue, Dec 01, 2015 at 02:45:27PM -0800, Dmitry Torokhov wrote: > > > > On Tue, Dec 1, 2015 at 2:32 PM, Sinclair Yeh <syeh at

On Thu, Jan 15, 2015 at 03:13:08PM +0100, Michal Hocko wrote: > On Thu 15-01-15 15:44:12, Michael S. Tsirkin wrote: > > On Thu, Jan 15, 2015 at 02:06:42PM +0100, Michal Hocko wrote: > > > On Thu 15-01-15 13:39:06, Michael S. Tsirkin wrote: > > > > Most of our code has > > > > struct foo { > > > > } > > > > > > > > Fix

On Thu, Jan 15, 2015 at 03:13:08PM +0100, Michal Hocko wrote: > On Thu 15-01-15 15:44:12, Michael S. Tsirkin wrote: > > On Thu, Jan 15, 2015 at 02:06:42PM +0100, Michal Hocko wrote: > > > On Thu 15-01-15 13:39:06, Michael S. Tsirkin wrote: > > > > Most of our code has > > > > struct foo { > > > > } > > > > > > > > Fix

On Tue, Jan 26, 2016 at 11:32:00AM +0100, Peter Zijlstra wrote: > On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > > > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > > specification (I seem to keep repeating this). > > Do we want this ? > > --- > Documentation/memory-barriers.txt | 17 +++++++++++++++++ > 1 file changed,

On Tue, Jan 26, 2016 at 11:32:00AM +0100, Peter Zijlstra wrote: > On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > > > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > > specification (I seem to keep repeating this). > > Do we want this ? > > --- > Documentation/memory-barriers.txt | 17 +++++++++++++++++ > 1 file changed,

Hello, I find a strange behavior. When a machine is slow (or with many debug traces or a qemu vm), a interrupt can occur between the pv_irq_ops initialization and the xen_vcpu[0] initialization. This lead to a problem because some operations in xen_irq_ops use xen_vcpu. I send you a patch to fix that but I''m not quite sure that is the right solution. Regards, Anthoine From

On Wed, Dec 02, 2015 at 09:26:34AM -0800, Dmitry Torokhov wrote: > On Wed, Dec 02, 2015 at 07:31:24AM -0800, Greg Kroah-Hartman wrote: > > On Tue, Dec 01, 2015 at 06:21:06PM -0800, Sinclair Yeh wrote: > > > On Tue, Dec 01, 2015 at 04:04:08PM -0800, Greg Kroah-Hartman wrote: > > > > On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote: > > > > >

On Wed, Dec 02, 2015 at 09:26:34AM -0800, Dmitry Torokhov wrote: > On Wed, Dec 02, 2015 at 07:31:24AM -0800, Greg Kroah-Hartman wrote: > > On Tue, Dec 01, 2015 at 06:21:06PM -0800, Sinclair Yeh wrote: > > > On Tue, Dec 01, 2015 at 04:04:08PM -0800, Greg Kroah-Hartman wrote: > > > > On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote: > > > > >

On Thu, Jan 15, 2015 at 02:06:42PM +0100, Michal Hocko wrote: > On Thu 15-01-15 13:39:06, Michael S. Tsirkin wrote: > > Most of our code has > > struct foo { > > } > > > > Fix two instances where balloon is inconsistent. > > I hate to complain but is it really necessary to post such patches to > linux-api? Well it's human to err, so it seems wise to

On Thu, Jan 15, 2015 at 02:06:42PM +0100, Michal Hocko wrote: > On Thu 15-01-15 13:39:06, Michael S. Tsirkin wrote: > > Most of our code has > > struct foo { > > } > > > > Fix two instances where balloon is inconsistent. > > I hate to complain but is it really necessary to post such patches to > linux-api? Well it's human to err, so it seems wise to