Hello all
Would like to come with a suggestion I have been wondering about for a
while, why not add the config-flag, used in Kconfig/Makefile in the
MAINTAINERS-file?
By doing this, there would not be any confusion who to send a patch,
since all "files" is defined under a flag, right? (when it is a
header-file, it can be grep'ed on the c-files and from the hit find the
flag)
So, with a MAINTAINERS-entry like:
SUPERCOOL ALPHA CARD
P: Clark Kent
M: [email protected]
L: [email protected]
C: SUPER_A
S: Maintained
(C: for CONFIG. Any better idea?)
then if someone changes a file who are built with CONFIG_SUPER_A, can
easily backtrack it to the correct maintainer(s). And because there is
no question how to find the correct maintainer, a script can do it for
us. This is something that would be really useful for Kernel-Janitors
when doing big cleanups all over the kernel (see ex pci_module_init to
pci_register_driver and standardize the tree to use macros from
include/linux/kernel.h).
By this, I believe trivial patch-series would be reduced from the lkml
when they can automatically be sent to the maintainer (and maybe
specified mailing-list).
My first idea was to use the pathway and define that directories above
the specified (if not specified by another) would fall to the current
maintainer. It would work, but requires that all pathways be specified
at once, or a few maintainers with "short" pathways would get much of
the patches (and it is not as correct/easy to maintain as looking for
the CONFIG_flag).
Any thoughts on this is very much appreciated (is there any flaws with
this?).
Richard Knutsson
On 13 Jan, Richard Knutsson wrote:
[...]
> SUPERCOOL ALPHA CARD
>
> P: Clark Kent
> M: [email protected]
> L: [email protected]
> C: SUPER_A
> S: Maintained
> (C: for CONFIG. Any better idea?)
>
> then if someone changes a file who are built with CONFIG_SUPER_A, can
> easily backtrack it to the correct maintainer(s).
[...]
> My first idea was to use the pathway and define that directories above
> the specified (if not specified by another) would fall to the current
> maintainer. It would work, but requires that all pathways be specified
> at once, or a few maintainers with "short" pathways would get much of
> the patches (and it is not as correct/easy to maintain as looking for
> the CONFIG_flag).
>
>
> Any thoughts on this is very much appreciated (is there any flaws with
> this?).
- What about drivers which have no MAINTAINER entry but reside in a
subsystem with MAINTAINER entry?
- What if these drivers depend on two subsystems?
- Config options map to object files but do not map directly to source
files. Diffstats show source files.
Example: The sbp2 driver is an IEEE 1394 driver and a SCSI driver.
sbp2.o is enabled by CONFIG_IEEE1394_SBP2 which depends on
CONFIG_IEEE1394 and CONFIG_SCSI. sbp2.c resides in drivers/ieee1394/.
What is the algorithm to look up sbp2's maintainers?
Don't get me wrong though. Easier lookup of maintainers and mailinglists
sounds to me like a desirable feature, not just from the point of view
of submitters but also of maintainers.
--
Stefan Richter
-=====-=-=== ---= -==-=
http://arcgraph.de/sr/
Stefan Richter wrote:
> On 13 Jan, Richard Knutsson wrote:
> [...]
>
>> SUPERCOOL ALPHA CARD
>>
>> P: Clark Kent
>> M: [email protected]
>> L: [email protected]
>> C: SUPER_A
>> S: Maintained
>> (C: for CONFIG. Any better idea?)
>>
>> then if someone changes a file who are built with CONFIG_SUPER_A, can
>> easily backtrack it to the correct maintainer(s).
>>
> [...]
>
>> My first idea was to use the pathway and define that directories above
>> the specified (if not specified by another) would fall to the current
>> maintainer. It would work, but requires that all pathways be specified
>> at once, or a few maintainers with "short" pathways would get much of
>> the patches (and it is not as correct/easy to maintain as looking for
>> the CONFIG_flag).
>>
>>
>> Any thoughts on this is very much appreciated (is there any flaws with
>> this?).
>>
>
> - What about drivers which have no MAINTAINER entry but reside in a
> subsystem with MAINTAINER entry?
>
Hmm, how are those drivers built? Can you please point me to one?
> - What if these drivers depend on two subsystems?
>
Not sure if I understand the problem. I don't see the maintainers for
the subsystems too interested in a driver, and it is the drivers
maintainer we want.
>
> - Config options map to object files but do not map directly to source
> files. Diffstats show source files.
>
Can you make a object-file out of 2 c-files? Using Makefile?
> Example: The sbp2 driver is an IEEE 1394 driver and a SCSI driver.
> sbp2.o is enabled by CONFIG_IEEE1394_SBP2 which depends on
> CONFIG_IEEE1394 and CONFIG_SCSI. sbp2.c resides in drivers/ieee1394/.
> What is the algorithm to look up sbp2's maintainers?
>
The one listed for CONFIG_IEEE1394_SBP2 :)
But what about ex ieee1394_core.o? Is ieee1394-objs "equal" to
ieee1394.o? (Seems I need to read some Makefile docs...)
> Don't get me wrong though. Easier lookup of maintainers and mailinglists
> sounds to me like a desirable feature, not just from the point of view
> of submitters but also of maintainers.
>
Well, as they say: "If it is too good to be true, it usually is" (but I
don't think it is too far fetched)
(Btw, what I can see, there is no possibility to get the wrong
maintainer. Just that sometime it can't give you an answer and you have
to do it in the old way).
Thanks for all the pointers!
Richard Knutsson wrote:
> Any thoughts on this is very much appreciated (is there any flaws with
> this?).
The thought that crossed my mind was:
Why not do the same thing that was done to the "Help"-file. (Before it
was superseded by Kconfig).
Originaly there was a central Help-file, with all the texts. Then it was
split and placed in each sub-dir. And later it was superseded by Kconfig.
On the other hand you could skip the intermediate step and just fold the
Maintainer-data directly into Kconfig, that way everything is "in one
place" and you could place a "Maintainers"-Button next to the
"Help"-Button in *config, or just display it alongside the help.
And MAYBE that would also lessen the "update-to-date"-problem, as you
can just write the MAINTAINERs-data when you create/update the
Kconfig-file. Which is a thing that creates much bigger pain when you
forget it accidently. ;-)
Oh, and it neadly solves the mapping-problem, for at least all
kernel-parts that have a Kconfig-option/Sub-Tree.
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
On 13 Jan, Richard Knutsson wrote:
> Stefan Richter wrote:
>> On 13 Jan, Richard Knutsson wrote:
>> [...]
>>
>>> SUPERCOOL ALPHA CARD
>>>
>>> P: Clark Kent
>>> M: [email protected]
>>> L: [email protected]
>>> C: SUPER_A
>>> S: Maintained
>>> (C: for CONFIG. Any better idea?)
>>>
>>> then if someone changes a file who are built with CONFIG_SUPER_A, can
>>> easily backtrack it to the correct maintainer(s).
>>>
>> [...]
>>
>>> My first idea was to use the pathway and define that directories above
>>> the specified (if not specified by another) would fall to the current
>>> maintainer. It would work, but requires that all pathways be specified
>>> at once, or a few maintainers with "short" pathways would get much of
>>> the patches (and it is not as correct/easy to maintain as looking for
>>> the CONFIG_flag).
>>>
>>>
>>> Any thoughts on this is very much appreciated (is there any flaws with
>>> this?).
>>>
>>
>> - What about drivers which have no MAINTAINER entry but reside in a
>> subsystem with MAINTAINER entry?
>>
> Hmm, how are those drivers built? Can you please point me to one?
I believe you read too quickly what I wrote, didn't you? :-)
The MAINTAINER file doesn't influence how drivers are built.
>> - What if these drivers depend on two subsystems?
>>
> Not sure if I understand the problem. I don't see the maintainers for
> the subsystems too interested in a driver, and it is the drivers
> maintainer we want.
I am specifically thinking of drivers which are maintained by the
subsystem maintainers. (Well, see below...)
Besides, the subsystem maintainer could point the submitter to a
more appropriate channel or ignore the submitter. (A submitter who
feels ignored is hopefully doing some more research then.) Also,
a driver maintainer certainly reads the mailinglist to which the
submitter posted.
>> - Config options map to object files but do not map directly to source
>> files. Diffstats show source files.
>>
> Can you make a object-file out of 2 c-files? Using Makefile?
Yes, you can, although I don't know if it is directly done in the
kernel build system. Of course what is often done is to make n object
files out of n c files, then link them to make 1 object file.
>> Example: The sbp2 driver is an IEEE 1394 driver and a SCSI driver.
>> sbp2.o is enabled by CONFIG_IEEE1394_SBP2 which depends on
>> CONFIG_IEEE1394 and CONFIG_SCSI. sbp2.c resides in drivers/ieee1394/.
>> What is the algorithm to look up sbp2's maintainers?
>>
> The one listed for CONFIG_IEEE1394_SBP2 :)
...OK, we /could/ write
IEEE 1394 SUBSYSTEM
C: IEEE1394
C: IEEE1394_OHCI1394
C: IEEE1394_SBP2
C: IEEE1394_DV1394 /* would better be put into a new own entry due to different status of maintenance level */
C: IEEE1394_VIDEO1394 /* that one perhaps too */
L: [email protected]
P: Ben and me
[...]
IEEE 1394 IPV4 DRIVER (eth1394)
C: IEEE1394_ETH1394
[...]
On the other hand, we could write
IEEE 1394 SUBSYSTEM
F: drivers/ieee1394
L: [email protected]
P: Ben and me
[...]
IEEE 1394 IPV4 DRIVER (eth1394)
F: drivers/ieee1394/eth1394
[...]
If it was done the latter way, i.e. using F: not C:, it could be
made a rule that the more specific entries come after more generic
entries. Thus the last match of multiple matches is the proper one.
In any case, the longest match is the proper one.
> But what about ex ieee1394_core.o? Is ieee1394-objs "equal" to
> ieee1394.o? (Seems I need to read some Makefile docs...)
Yes and yes. (Documentation/kbuild/makefiles.txt)
>> Don't get me wrong though. Easier lookup of maintainers and mailinglists
>> sounds to me like a desirable feature, not just from the point of view
>> of submitters but also of maintainers.
>>
> Well, as they say: "If it is too good to be true, it usually is" (but I
> don't think it is too far fetched)
No, it probably isn't.
> (Btw, what I can see, there is no possibility to get the wrong
> maintainer. Just that sometime it can't give you an answer and you have
> to do it in the old way).
Your approach could give a wrong answer if someone implements a
very "clever" mapping. My approach could give a wrong answer if
someone takes a generic match while there was a more specific
match.
Your approach requires to evaluate the diffstat, one or more
Makefile (taking the Linux Makefile syntax into account), and the
MAINTAINERS file. My approach just requires to evaluate the
diffstat and the MAINTAINERS file.
--
Stefan Richter
-=====-=-=== ---= -==-=
http://arcgraph.de/sr/
Stefan Richter wrote:
> On 13 Jan, Richard Knutsson wrote:
>
>> Stefan Richter wrote:
>>
>>> On 13 Jan, Richard Knutsson wrote:
>>> [...]
>>>
>>>
>>>> SUPERCOOL ALPHA CARD
>>>>
>>>> P: Clark Kent
>>>> M: [email protected]
>>>> L: [email protected]
>>>> C: SUPER_A
>>>> S: Maintained
>>>> (C: for CONFIG. Any better idea?)
>>>>
>>>> then if someone changes a file who are built with CONFIG_SUPER_A, can
>>>> easily backtrack it to the correct maintainer(s).
>>>>
>>>>
>>> [...]
>>>
>>>
>>>> My first idea was to use the pathway and define that directories above
>>>> the specified (if not specified by another) would fall to the current
>>>> maintainer. It would work, but requires that all pathways be specified
>>>> at once, or a few maintainers with "short" pathways would get much of
>>>> the patches (and it is not as correct/easy to maintain as looking for
>>>> the CONFIG_flag).
>>>>
>>>>
>>>> Any thoughts on this is very much appreciated (is there any flaws with
>>>> this?).
>>>>
>>>>
>>> - What about drivers which have no MAINTAINER entry but reside in a
>>> subsystem with MAINTAINER entry?
>>>
>>>
>> Hmm, how are those drivers built? Can you please point me to one?
>>
>
> I believe you read too quickly what I wrote, didn't you? :-)
> The MAINTAINER file doesn't influence how drivers are built.
>
What the... now I have no idea why I deleted the previous text... oh
well, I tried 'grep -Er "^M\:" */*' but did not find any such entries.
Or did you mean files just stating "I maintaining this file"?
At least I know so much about the building-process that I don't think
MAINTAINER is involved :). It was meant as: how is a driver build
without some CONFIG_-flag set, but not sure now what I wanted with that
(blaming low blood-suger, got a pizza since then).
>
>>> - What if these drivers depend on two subsystems?
>>>
>>>
>> Not sure if I understand the problem. I don't see the maintainers for
>> the subsystems too interested in a driver, and it is the drivers
>> maintainer we want.
>>
>
> I am specifically thinking of drivers which are maintained by the
> subsystem maintainers. (Well, see below...)
>
More then one subsystem maintainers that is maintainers to a driver? I
would think one off those would quite naturally become the maintainer of
the driver and then accepting patches from the rest.
> Besides, the subsystem maintainer could point the submitter to a
> more appropriate channel or ignore the submitter. (A submitter who
> feels ignored is hopefully doing some more research then.) Also,
> a driver maintainer certainly reads the mailinglist to which the
> submitter posted.
>
Hopefully, but I think it is asking much of the maintainer and then
there will certanly be confused/frustrated submitter who don't know why
they don't get any answer nor patched included. We have already seen a
few asking about what happened with their patches.
>>> - Config options map to object files but do not map directly to source
>>> files. Diffstats show source files.
>>>
>>>
>> Can you make a object-file out of 2 c-files? Using Makefile?
>>
>
> Yes, you can, although I don't know if it is directly done in the
> kernel build system. Of course what is often done is to make n object
> files out of n c files, then link them to make 1 object file.
>
How?:
gcc -c test.c test2.c -o test3.o
gcc: cannot specify -o with -c or -S with multiple files
(with only -c i got test.o and test2.o)
In the kernel building system, an object-file is made from a c- or
s-file with the same name. Then, of course, they can be put together to
a larger object-file.
>>> Example: The sbp2 driver is an IEEE 1394 driver and a SCSI driver.
>>> sbp2.o is enabled by CONFIG_IEEE1394_SBP2 which depends on
>>> CONFIG_IEEE1394 and CONFIG_SCSI. sbp2.c resides in drivers/ieee1394/.
>>> What is the algorithm to look up sbp2's maintainers?
>>>
>>>
>> The one listed for CONFIG_IEEE1394_SBP2 :)
>>
>
> ...OK, we /could/ write
>
> IEEE 1394 SUBSYSTEM
> C: IEEE1394
> C: IEEE1394_OHCI1394
> C: IEEE1394_SBP2
> C: IEEE1394_DV1394 /* would better be put into a new own entry due to different status of maintenance level */
> C: IEEE1394_VIDEO1394 /* that one perhaps too */
> L: [email protected]
> P: Ben and me
> [...]
> IEEE 1394 IPV4 DRIVER (eth1394)
> C: IEEE1394_ETH1394
> [...]
>
What about possibility to replace it with:
C: IEEE1394*
and use the same system as with the path-approach, "longest wins". (I
don't think just IEEE1394 is appropriate, since then there is
possibility with false-positives again)
> On the other hand, we could write
>
> IEEE 1394 SUBSYSTEM
> F: drivers/ieee1394
> L: [email protected]
> P: Ben and me
> [...]
> IEEE 1394 IPV4 DRIVER (eth1394)
> F: drivers/ieee1394/eth1394
> [...]
>
> If it was done the latter way, i.e. using F: not C:, it could be
> made a rule that the more specific entries come after more generic
> entries. Thus the last match of multiple matches is the proper one.
> In any case, the longest match is the proper one.
>
As I wrote in the initial mail, my first idea was like that. But how to
solve when different drivers (with of course different maintainers) lies
in the same directory?
I thought something like include/linux/config.h,autoconf.h could be used
when referring to a few specific files in a directory. But there is also
the problem that all mails were the maintainer has no F: will fall in
the lap of the "good" maintainer with the shorter pathway, and I'm
afraid this might make people hesitant to add the F:.
>
>> But what about ex ieee1394_core.o? Is ieee1394-objs "equal" to
>> ieee1394.o? (Seems I need to read some Makefile docs...)
>>
>
> Yes and yes. (Documentation/kbuild/makefiles.txt)
>
Thanks
>> (Btw, what I can see, there is no possibility to get the wrong
>> maintainer. Just that sometime it can't give you an answer and you have
>> to do it in the old way).
>>
>
> Your approach could give a wrong answer if someone implements a
> very "clever" mapping. My approach could give a wrong answer if
> someone takes a generic match while there was a more specific
> match.
>
> Your approach requires to evaluate the diffstat, one or more
> Makefile (taking the Linux Makefile syntax into account), and the
> MAINTAINERS file. My approach just requires to evaluate the
> diffstat and the MAINTAINERS file.
>
Can't disagree on any. It is just the problems with false-positives and
picking out specific files that made me reconsider.
Matthias Schniedermeyer wrote:
> Richard Knutsson wrote:
>
>
>> Any thoughts on this is very much appreciated (is there any flaws with
>> this?).
>>
>
> The thought that crossed my mind was:
>
> Why not do the same thing that was done to the "Help"-file. (Before it
> was superseded by Kconfig).
>
> Originaly there was a central Help-file, with all the texts. Then it was
> split and placed in each sub-dir. And later it was superseded by Kconfig.
>
> On the other hand you could skip the intermediate step and just fold the
> Maintainer-data directly into Kconfig, that way everything is "in one
> place" and you could place a "Maintainers"-Button next to the
> "Help"-Button in *config, or just display it alongside the help.
>
> And MAYBE that would also lessen the "update-to-date"-problem, as you
> can just write the MAINTAINERs-data when you create/update the
> Kconfig-file. Which is a thing that creates much bigger pain when you
> forget it accidently. ;-)
>
> Oh, and it neadly solves the mapping-problem, for at least all
> kernel-parts that have a Kconfig-option/Sub-Tree.
>
I'm all for splitting up the MAINTAINERS! :)
Just, do you have any ideas how to solve the possible multiple of the
same entries, when handling multiple sub-directories and when many
different drivers with different maintainers are in the same directory
and a maintainer have more then one driver?
Richard Knutsson wrote:
> Matthias Schniedermeyer wrote:
>
>> Richard Knutsson wrote:
>>
>>
>>
>>> Any thoughts on this is very much appreciated (is there any flaws with
>>> this?).
>>>
>>
>>
>> The thought that crossed my mind was:
>>
>> Why not do the same thing that was done to the "Help"-file. (Before it
>> was superseded by Kconfig).
>>
>> Originaly there was a central Help-file, with all the texts. Then it was
>> split and placed in each sub-dir. And later it was superseded by Kconfig.
>>
>> On the other hand you could skip the intermediate step and just fold the
>> Maintainer-data directly into Kconfig, that way everything is "in one
>> place" and you could place a "Maintainers"-Button next to the
>> "Help"-Button in *config, or just display it alongside the help.
>>
>> And MAYBE that would also lessen the "update-to-date"-problem, as you
>> can just write the MAINTAINERs-data when you create/update the
>> Kconfig-file. Which is a thing that creates much bigger pain when you
>> forget it accidently. ;-)
>>
>> Oh, and it neadly solves the mapping-problem, for at least all
>> kernel-parts that have a Kconfig-option/Sub-Tree.
>>
>
> I'm all for splitting up the MAINTAINERS! :)
>
> Just, do you have any ideas how to solve the possible multiple of the
> same entries, when handling multiple sub-directories and when many
> different drivers with different maintainers are in the same directory
> and a maintainer have more then one driver?
Handles.
If a Maintainer maintains several subsystems/drivers a "handle" could be
used to references to a handle-list (hello MAINTAINERS) or to the place
where the full-maintainers-entry is placed.
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
On 14 Jan, Richard Knutsson wrote:
> Stefan Richter wrote:
[getting a wrong contact from looking at the MAINTAINERS file]
> Hopefully, but I think it is asking much of the maintainer and then
> there will certanly be confused/frustrated submitter who don't know why
> they don't get any answer nor patched included. We have already seen a
> few asking about what happened with their patches.
Sure. But such glitches occur due to lack of research by the submitter
or due to missing information about maintainers. Neither one would be
made worse nor cured by adding script-readable references to sources or
config options to the MAINTAINERS file.
>>> Can you make a object-file out of 2 c-files? Using Makefile?
>>
>> Yes, you can, although I don't know if it is directly done in the
>> kernel build system.
[...]
> How?:
> gcc -c test.c test2.c -o test3.o
> gcc: cannot specify -o with -c or -S with multiple files
> (with only -c i got test.o and test2.o)
gcc -o test3.o test.c test.c
> In the kernel building system, an object-file is made from a c- or
> s-file with the same name. Then, of course, they can be put together to
> a larger object-file.
[...]
[multiple references in one maintainer record]
> What about possibility to replace it with:
>
> C: IEEE1394*
>
> and use the same system as with the path-approach, "longest wins". (I
> don't think just IEEE1394 is appropriate, since then there is
> possibility with false-positives again)
I doubt that wildcards (or maybe regular expressions) are really needed.
But this can only be found out by going through some non-trivial cases.
>> On the other hand, we could write
>>
>> IEEE 1394 SUBSYSTEM
>> F: drivers/ieee1394
>> L: [email protected]
>> P: Ben and me
>> [...]
>> IEEE 1394 IPV4 DRIVER (eth1394)
>> F: drivers/ieee1394/eth1394
>> [...]
>>
>> If it was done the latter way, i.e. using F: not C:, it could be
>> made a rule that the more specific entries come after more generic
>> entries. Thus the last match of multiple matches is the proper one.
>> In any case, the longest match is the proper one.
>>
> As I wrote in the initial mail, my first idea was like that. But how to
> solve when different drivers (with of course different maintainers) lies
> in the same directory?
To continue my above example:
IEEE 1394 PCILYNX DRIVER
F: drivers/ieee1394/pcilynx
Should work. Note, the substrings "eth1394" and "pcilynx" do not denote
subdirectories. They are substrings of the paths to these drivers'
sources nonetheless.
> I thought something like include/linux/config.h,autoconf.h could be used
> when referring to a few specific files in a directory. But there is also
> the problem that all mails were the maintainer has no F: will fall in
> the lap of the "good" maintainer with the shorter pathway, and I'm
> afraid this might make people hesitant to add the F:.
1. The same can be said about the C: method, or about the status quo.
2. The patches will typically be Cced to the respective mailinglist
where the driver maintainer can harvest the patch or can send an ACK
or NAK as a signal to the subsystem maintainer whether to pick it up.
3. When people notice that patches are misdirected too often, they will
update MAINTAINERS.
[...]
> It is just the problems with false-positives and picking out specific
> files that made me reconsider.
May I remind that whoever uses scripts to figure out contacts should
better double-check what the script found out for him. (Regardless
whether the script grepped for config options or for path components.)
There are carbon-based lifeforms on the receiving end.
BTW, it seems to me like the F: approach is easier than the C: one when
it comes to patches which touch only .h files. It is already somewhat
costly to backtrack .c files from .o files from config options, but
considerably more so with .h files.
--
Stefan Richter
-=====-=-=== ---= -===-
http://arcgraph.de/sr/
I wrote:
> gcc -o test3.o test.c test.c
^^ typo
gcc -o test3.o test.c test2.c
--
Stefan Richter
-=====-=-=== ---= -===-
http://arcgraph.de/sr/
Stefan Richter wrote:
> On 14 Jan, Richard Knutsson wrote:
>
>> Stefan Richter wrote:
>>
> [getting a wrong contact from looking at the MAINTAINERS file]
>
>> Hopefully, but I think it is asking much of the maintainer and then
>> there will certanly be confused/frustrated submitter who don't know why
>> they don't get any answer nor patched included. We have already seen a
>> few asking about what happened with their patches.
>>
>
> Sure. But such glitches occur due to lack of research by the submitter
> or due to missing information about maintainers. Neither one would be
> made worse nor cured by adding script-readable references to sources or
> config options to the MAINTAINERS file.
>
I suspect I have misunderstood your idea. Correct me if this is wrong:
if you add:
F: drivers/pci
Then also the directories hotplug and pcie (and its content) will fall
to that entry, unless there is someone adding:
F: drivers/pci/hotplug
in their entry.
With the approach I suggested that is not possible (unless introducing
wildcards).
Also, a maintainer for the "hotplug" have to add:
F: drivers/pci/hotplug
F: drivers/pci/setup-bus
or
C: HOTPLUG
and what will hinder it from including drivers/pci/hotplug/ other then
adding the F: on PCI Hotplugs maintainer? (yes, this is no real problem
since they probably are the same maintainer or just add the F: )
>>>> Can you make a object-file out of 2 c-files? Using Makefile?
>>>>
>>> Yes, you can, although I don't know if it is directly done in the
>>> kernel build system.
>>>
> [...]
>
>> How?:
>> gcc -c test.c test2.c -o test3.o
>> gcc: cannot specify -o with -c or -S with multiple files
>> (with only -c i got test.o and test2.o)
>>
>
> gcc -o test3.o test.c test.c
>
That produces just an executable file with a misleading name :) (test
with two files were neither has a 'main()')
You need the '-c'-flag to tell the gcc just make them to object-files.
>
>> In the kernel building system, an object-file is made from a c- or
>> s-file with the same name. Then, of course, they can be put together to
>> a larger object-file.
>>
> [...]
> [multiple references in one maintainer record]
>
>> What about possibility to replace it with:
>>
>> C: IEEE1394*
>>
>> and use the same system as with the path-approach, "longest wins". (I
>> don't think just IEEE1394 is appropriate, since then there is
>> possibility with false-positives again)
>>
>
> I doubt that wildcards (or maybe regular expressions) are really needed.
> But this can only be found out by going through some non-trivial cases.
>
Mm, that is just a feature. Best to get the basics straighten out first :)
>>> On the other hand, we could write
>>>
>>> IEEE 1394 SUBSYSTEM
>>> F: drivers/ieee1394
>>> L: [email protected]
>>> P: Ben and me
>>> [...]
>>> IEEE 1394 IPV4 DRIVER (eth1394)
>>> F: drivers/ieee1394/eth1394
>>> [...]
>>>
>>> If it was done the latter way, i.e. using F: not C:, it could be
>>> made a rule that the more specific entries come after more generic
>>> entries. Thus the last match of multiple matches is the proper one.
>>> In any case, the longest match is the proper one.
>>>
>>>
>> As I wrote in the initial mail, my first idea was like that. But how to
>> solve when different drivers (with of course different maintainers) lies
>> in the same directory?
>>
>
> To continue my above example:
>
> IEEE 1394 PCILYNX DRIVER
> F: drivers/ieee1394/pcilynx
>
> Should work. Note, the substrings "eth1394" and "pcilynx" do not denote
> subdirectories. They are substrings of the paths to these drivers'
> sources nonetheless.
>
Absolutely, also it can easily refer to the "include header-files" by:
F: include/linux/pci.h
which is not as easily done in "my" way. The local headers are ok I
think as the c-files that includes it should have the same maintainer,
but ex pci.h are used by _quite_ many drivers. But is the headers in the
include/-directory just a matter for the maintainer since they are
globally reachable. But I think this is _the_ downside of that approach.
>> I thought something like include/linux/config.h,autoconf.h could be used
>> when referring to a few specific files in a directory. But there is also
>> the problem that all mails were the maintainer has no F: will fall in
>> the lap of the "good" maintainer with the shorter pathway, and I'm
>> afraid this might make people hesitant to add the F:.
>>
>
> 1. The same can be said about the C: method, or about the status quo.
>
No, since it is either a hit or it is not. Without wildcards, an entry like:
C: CONFIG_IEEE1394
would not pick up ex CONFIG_IEEE1394_RAWIO.
> 2. The patches will typically be Cced to the respective mailinglist
> where the driver maintainer can harvest the patch or can send an ACK
> or NAK as a signal to the subsystem maintainer whether to pick it up.
> 3. When people notice that patches are misdirected too often, they will
> update MAINTAINERS.
>
You mean they update other maintainers entries? That would be good...
> [...]
>
>> It is just the problems with false-positives and picking out specific
>> files that made me reconsider.
>>
>
> May I remind that whoever uses scripts to figure out contacts should
> better double-check what the script found out for him. (Regardless
> whether the script grepped for config options or for path components.)
> There are carbon-based lifeforms on the receiving end.
>
During development, that's a given. But I would hope that when its more
stable it will always find the right answer or no answer at all (if
there is errors in ex MAINTAINERS, even the human will bother the receiver)
> BTW, it seems to me like the F: approach is easier than the C: one when
> it comes to patches which touch only .h files. It is already somewhat
> costly to backtrack .c files from .o files from config options, but
> considerably more so with .h files.
>
I think it is to early to be thinking about what is easier, first a
"algorithm" that does what we want is needed, then I'm more then happy
to write a script/program for it :)
Costly?? It is even simple in bash:
C_FILE=${O_FILE/'.o'/'.c'}
this have then just to be checked if existing, otherwise it is a
.s-file. And this is just a userspace-application, if it takes a minute
to go throe 200 files I think that is no problem, just gives the
programmer time to drink another Jolt Cola.
The main reason I hold on my idea is that I would like to use the
build-system to insure any changes with filenames or such, do not mean
any changing to MAINTAINERS (aka, can you build the driver, you will
find the maintainer if they have added it to their entry). But was just
thinking, what about using something like (this may be the best of the two):
C: THE_CONFIG_FLAG
I: linux/global-header.h
(I: for "include". Btw, what is F: standing for? Is it instead of P:?)
I: may be extended for other headers also but I can't think of any use
since a header included by a file in the same directory or a directory
above (shorter pathway) (have seen use of special h-directories just for
the header-files. It may cost a cycle or two, but as I said: userspace
and I think the programmer will waste many more when just
correct-reading the patch :)
Matthias Schniedermeyer wrote:
> Richard Knutsson wrote:
>
>> Matthias Schniedermeyer wrote:
>>
>>
>>> Richard Knutsson wrote:
>>>
>>>
>>>
>>>
>>>> Any thoughts on this is very much appreciated (is there any flaws with
>>>> this?).
>>>>
>>>>
>>> The thought that crossed my mind was:
>>>
>>> Why not do the same thing that was done to the "Help"-file. (Before it
>>> was superseded by Kconfig).
>>>
>>> Originaly there was a central Help-file, with all the texts. Then it was
>>> split and placed in each sub-dir. And later it was superseded by Kconfig.
>>>
>>> On the other hand you could skip the intermediate step and just fold the
>>> Maintainer-data directly into Kconfig, that way everything is "in one
>>> place" and you could place a "Maintainers"-Button next to the
>>> "Help"-Button in *config, or just display it alongside the help.
>>>
>>> And MAYBE that would also lessen the "update-to-date"-problem, as you
>>> can just write the MAINTAINERs-data when you create/update the
>>> Kconfig-file. Which is a thing that creates much bigger pain when you
>>> forget it accidently. ;-)
>>>
>>> Oh, and it neadly solves the mapping-problem, for at least all
>>> kernel-parts that have a Kconfig-option/Sub-Tree.
>>>
>>>
>> I'm all for splitting up the MAINTAINERS! :)
>>
>> Just, do you have any ideas how to solve the possible multiple of the
>> same entries, when handling multiple sub-directories and when many
>> different drivers with different maintainers are in the same directory
>> and a maintainer have more then one driver?
>>
>
> Handles.
> If a Maintainer maintains several subsystems/drivers a "handle" could be
> used to references to a handle-list (hello MAINTAINERS) or to the place
> where the full-maintainers-entry is placed.
>
Mm, and maybe store the entry on the shortest-pathway common directory.
Then there should be just a few left entries in the current MAINTAINERS.
But how to create the handles?
* Name (problem with persons with the same name)
* E-mail (much to change when they change it)
This also make a problem when there is a change of the maintainer, what
happens with the entry if there is no maintainer?
* Just numbers and increase every new one with one? (quite ugly!)
... and here is the end of my ideas.
Any good ideas? (Really liked the idea to have a "Maintainer"-button
next to "Help" in *config)
On 14 Jan, Richard Knutsson wrote:
> Stefan Richter wrote:
>> gcc -o test3.o test.c test.c
>>
> That produces just an executable file with a misleading name :)
#-)
[...]
>> 3. When people notice that patches are misdirected too often, they will
>> update MAINTAINERS.
>>
> You mean they update other maintainers entries? That would be good...
Strictly spoken, only Linus updates MAINTAINERS. Everybody else merely
sends change requests which are forwarded or rejected. If newbie John
Doe finds there is something missing in MAINTAINERS, he could send a
proper patch *to the proper contacts*, et voil?. In short, people
including John Doe updated MAINTAINERS.
[...]
>> May I remind that whoever uses scripts to figure out contacts should
>> better double-check what the script found out for him.
[...]
> During development, that's a given. But I would hope that when its more
> stable it will always find the right answer or no answer at all (if
> there is errors in ex MAINTAINERS, even the human will bother the receiver)
Note, if people build scripts which look up contacts, I hope they don't
become careless and forget to search elsewhere for proper contacts if
_no_ contact was found automatically.
[...]
>> It is already somewhat
>> costly to backtrack .c files from .o files from config options, but
>> considerably more so with .h files.
>>
> I think it is to early to be thinking about what is easier, first a
> "algorithm" that does what we want is needed, then I'm more then happy
> to write a script/program for it :)
> Costly?? It is even simple in bash:
> C_FILE=${O_FILE/'.o'/'.c'}
When I wrote "somewhat costly" I didn't refer to a 1:1 mapping between
.c and .o. That's not what it takes. I mostly referred to having to
implement a parser for parts of the Linux Makefile language. On the
bright side, the more indirection you introduce, the less people will
write their own scripts and the less scripts with bugs will be out
there. :-)
[...]
> (I: for "include". Btw, what is F: standing for? Is it instead of P:?)
[...]
Doesn't need to be F. "Files" happens to start with F.
--
Stefan Richter
-=====-=-=== ---= -===-
http://arcgraph.de/sr/
On 14 Jan, Richard Knutsson wrote:
> (Really liked the idea to have a "Maintainer"-button
> next to "Help" in *config)
Rhetorical question: What will this button be used for?
--
Stefan Richter
-=====-=-=== ---= -===-
http://arcgraph.de/sr/
Richard Knutsson wrote:
> Matthias Schniedermeyer wrote:
>
>> Richard Knutsson wrote:
>>
>>
>>> Matthias Schniedermeyer wrote:
>>>
>>>
>>>
>>>> Richard Knutsson wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Any thoughts on this is very much appreciated (is there any flaws with
>>>>> this?).
>>>>>
>>>>
>>>> The thought that crossed my mind was:
>>>>
>>>> Why not do the same thing that was done to the "Help"-file. (Before it
>>>> was superseded by Kconfig).
>>>>
>>>> Originaly there was a central Help-file, with all the texts. Then it
>>>> was
>>>> split and placed in each sub-dir. And later it was superseded by
>>>> Kconfig.
>>>>
>>>> On the other hand you could skip the intermediate step and just fold
>>>> the
>>>> Maintainer-data directly into Kconfig, that way everything is "in one
>>>> place" and you could place a "Maintainers"-Button next to the
>>>> "Help"-Button in *config, or just display it alongside the help.
>>>>
>>>> And MAYBE that would also lessen the "update-to-date"-problem, as you
>>>> can just write the MAINTAINERs-data when you create/update the
>>>> Kconfig-file. Which is a thing that creates much bigger pain when you
>>>> forget it accidently. ;-)
>>>>
>>>> Oh, and it neadly solves the mapping-problem, for at least all
>>>> kernel-parts that have a Kconfig-option/Sub-Tree.
>>>>
>>>
>>> I'm all for splitting up the MAINTAINERS! :)
>>>
>>> Just, do you have any ideas how to solve the possible multiple of the
>>> same entries, when handling multiple sub-directories and when many
>>> different drivers with different maintainers are in the same directory
>>> and a maintainer have more then one driver?
>>>
>>
>>
>> Handles.
>> If a Maintainer maintains several subsystems/drivers a "handle" could be
>> used to references to a handle-list (hello MAINTAINERS) or to the place
>> where the full-maintainers-entry is placed.
>>
>
> Mm, and maybe store the entry on the shortest-pathway common directory.
> Then there should be just a few left entries in the current MAINTAINERS.
> But how to create the handles?
> * Name (problem with persons with the same name)
> * E-mail (much to change when they change it)
> This also make a problem when there is a change of the maintainer, what
> happens with the entry if there is no maintainer?
> * Just numbers and increase every new one with one? (quite ugly!)
> ... and here is the end of my ideas.
>
> Any good ideas? (Really liked the idea to have a "Maintainer"-button
> next to "Help" in *config)
I'd say something like:
<Initials/ShortenedName><Numbers>
e.g.
MS0001
MaSchn001
or something along that line.
Some people have several entries in the MAINTAINERs and a new way would
have to make that possible too.
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
Stefan Richter wrote:
> On 14 Jan, Richard Knutsson wrote:
>
>>(Really liked the idea to have a "Maintainer"-button
>>next to "Help" in *config)
>
>
> Rhetorical question: What will this button be used for?
Having "all(tm)" information of something in one place?
Help-Text and Dependencies/Selects are already there.
I think adding the Maintainers-data is more or less a logical next step.
It's not always clear from the MAINTAINERS-file who is the right person
for what. Especially as it is a rather large text-file with only
mediocre search-friendlieness. It's a 3.5 K-lines file!
So when you know that you have a problem with drivers X, wouldn't it be
great if you could just "go to" the driver in *config and see not only
the Help-Text but the Maintainers-Data also.
And you can place "Fallback"-Maintainers-Data on Tree-Parents, for the
cases where you only can pinpoint a area, like when you have a problem
with a USB-device.
I can ask a rhetorical question too:
Why not go back to Config.help. Having a huge X K-Lines file with
everything in one file can't be that bad. It worked before!
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
On 15 Jan, Matthias Schniedermeyer wrote:
> Stefan Richter wrote:
>> On 14 Jan, Richard Knutsson wrote:
>>>(Really liked the idea to have a "Maintainer"-button
>>>next to "Help" in *config)
>>
>> Rhetorical question: What will this button be used for?
>
> Having "all(tm)" information of something in one place?
Or, "click here to say 'it does not work'"?
My rhetorical question wasn't about what it is intended for, but what
people would think it was intended for if it was there.
> Help-Text and Dependencies/Selects are already there.
Yes. For the purpose of configuring the kernel.
> I think adding the Maintainers-data is more or less a logical next step.
>
> It's not always clear from the MAINTAINERS-file who is the right person
> for what. Especially as it is a rather large text-file with only
> mediocre search-friendlieness. It's a 3.5 K-lines file!
>
> So when you know that you have a problem with drivers X, wouldn't it be
> great if you could just "go to" the driver in *config and see not only
> the Help-Text but the Maintainers-Data also.
Seems more like what you actually want to have there is links to users'
mailinglists or forums.
When this thread started, it was about assisting authors in submitting
patches.
> And you can place "Fallback"-Maintainers-Data on Tree-Parents, for the
> cases where you only can pinpoint a area, like when you have a problem
> with a USB-device.
>
>
> I can ask a rhetorical question too:
> Why not go back to Config.help. Having a huge X K-Lines file with
> everything in one file can't be that bad. It worked before!
I am in no way against Richard's plan to improve development and
maintenance processes by easier access to contact data.
--
Stefan Richter
-=====-=-=== ---= -====
http://arcgraph.de/sr/
Stefan Richter wrote:
> On 15 Jan, Matthias Schniedermeyer wrote:
>
>> Stefan Richter wrote:
>>
>>> On 14 Jan, Richard Knutsson wrote:
>>>
>>>> (Really liked the idea to have a "Maintainer"-button
>>>> next to "Help" in *config)
>>>>
>>> Rhetorical question: What will this button be used for?
>>>
>> Having "all(tm)" information of something in one place?
>>
>
> Or, "click here to say 'it does not work'"?
>
> My rhetorical question wasn't about what it is intended for, but what
> people would think it was intended for if it was there.
>
>
I think it could be practical to have an easy access to whom is
responsible for a driver and which mailinglist its development is
addressed to, both for people interested in helping develop the driver
and those who got an error (or fan-mail :).
>> I think adding the Maintainers-data is more or less a logical next step.
>>
>> It's not always clear from the MAINTAINERS-file who is the right person
>> for what. Especially as it is a rather large text-file with only
>> mediocre search-friendlieness. It's a 3.5 K-lines file!
>>
>> So when you know that you have a problem with drivers X, wouldn't it be
>> great if you could just "go to" the driver in *config and see not only
>> the Help-Text but the Maintainers-Data also.
>>
>
> Seems more like what you actually want to have there is links to users'
> mailinglists or forums.
>
> When this thread started, it was about assisting authors in submitting
> patches.
>
>
Yes, this is a bit out of scope, but just realized a simple way to
implement it if using the CONFIG_FLAG-approach, just "grep" after the
flag, under which the user hit the "Maintainer"-button, in the
MAINTAINER-file. Also, I think this solves the handler-problem since an
entry can have multiple CONFIG_FLAG's stated.
I don't think we should add the maintainer-entries directly in Kconfig,
as you Stefan stated, because it is for configure the kernel. With the
above approach, it will just require minor fixes in the "make *config"
to handle it.
Stefan Richter wrote:
> On 14 Jan, Richard Knutsson wrote:
>
>> Stefan Richter wrote:
>>
>>> May I remind that whoever uses scripts to figure out contacts should
>>> better double-check what the script found out for him.
>>>
> [...]
>
>> During development, that's a given. But I would hope that when its more
>> stable it will always find the right answer or no answer at all (if
>> there is errors in ex MAINTAINERS, even the human will bother the receiver)
>>
>
> Note, if people build scripts which look up contacts, I hope they don't
> become careless and forget to search elsewhere for proper contacts if
> _no_ contact was found automatically.
>
Maybe the script may print out some pointers for such a case ;)
> [...]
>
>>> It is already somewhat
>>> costly to backtrack .c files from .o files from config options, but
>>> considerably more so with .h files.
>>>
>>>
>> I think it is to early to be thinking about what is easier, first a
>> "algorithm" that does what we want is needed, then I'm more then happy
>> to write a script/program for it :)
>> Costly?? It is even simple in bash:
>> C_FILE=${O_FILE/'.o'/'.c'}
>>
>
> When I wrote "somewhat costly" I didn't refer to a 1:1 mapping between
> .c and .o. That's not what it takes. I mostly referred to having to
> implement a parser for parts of the Linux Makefile language. On the
> bright side, the more indirection you introduce, the less people will
> write their own scripts and the less scripts with bugs will be out
> there. :-)
>
>
Oh, yes so it is. But I don't think it will be too much. But do you have
any objections on the last proposal (to include "I:"), otherwise I
thinking of trying to implement it (thinking of Perl, any reason to not
do so?) to see if it can stand real usage.
Hope so (on bugs that is, always fun with scripts) :)
> [...]
>
>> (I: for "include". Btw, what is F: standing for? Is it instead of P:?)
>>
> [...]
>
> Doesn't need to be F. "Files" happens to start with F.
>
Doh, was in the track of "pathway" or such...
Richard Knutsson wrote:
> Stefan Richter wrote:
>
>> On 15 Jan, Matthias Schniedermeyer wrote:
>>
>>
>>> Stefan Richter wrote:
>>>
>>>
>>>> On 14 Jan, Richard Knutsson wrote:
>>>>
>>>>
>>>>> (Really liked the idea to have a "Maintainer"-button next to "Help"
>>>>> in *config)
>>>>>
>>>>
>>>> Rhetorical question: What will this button be used for?
>>>>
>>>
>>> Having "all(tm)" information of something in one place?
>>>
>>
>>
>> Or, "click here to say 'it does not work'"?
>>
>> My rhetorical question wasn't about what it is intended for, but what
>> people would think it was intended for if it was there.
>>
>>
>
> I think it could be practical to have an easy access to whom is
> responsible for a driver and which mailinglist its development is
> addressed to, both for people interested in helping develop the driver
> and those who got an error (or fan-mail :).
>
>>> I think adding the Maintainers-data is more or less a logical next step.
>>>
>>> It's not always clear from the MAINTAINERS-file who is the right person
>>> for what. Especially as it is a rather large text-file with only
>>> mediocre search-friendlieness. It's a 3.5 K-lines file!
>>>
>>> So when you know that you have a problem with drivers X, wouldn't it be
>>> great if you could just "go to" the driver in *config and see not only
>>> the Help-Text but the Maintainers-Data also.
>>>
>>
>>
>> Seems more like what you actually want to have there is links to users'
>> mailinglists or forums.
>>
>> When this thread started, it was about assisting authors in submitting
>> patches.
>>
>>
>
> Yes, this is a bit out of scope, but just realized a simple way to
> implement it if using the CONFIG_FLAG-approach, just "grep" after the
> flag, under which the user hit the "Maintainer"-button, in the
> MAINTAINER-file. Also, I think this solves the handler-problem since an
> entry can have multiple CONFIG_FLAG's stated.
>
> I don't think we should add the maintainer-entries directly in Kconfig,
> as you Stefan stated, because it is for configure the kernel. With the
> above approach, it will just require minor fixes in the "make *config"
> to handle it.
But how do you suppose the user gets the CONFIG_-String, which the user
then could for searching?
I'd say only a small percentage of hardcore-users would use the
.config-file directly, the others would deviate over *config, so i'd say
if the MAINTAINERS-data is integrated into Kconfig it's the perfect(tm)
90% solution.
OTOH you could just teach the *config to lookup a MAINTAINERS-entry when
all they are properly flagged.
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
On 15 Jan, Richard Knutsson was...
> thinking of trying to implement it
I'd say go ahead and test your idea.
--
Stefan Richter
-=====-=-=== ---= -====
http://arcgraph.de/sr/
Matthias Schniedermeyer wrote:
> Richard Knutsson wrote:
>
>> Stefan Richter wrote:
>>
>>
>>> On 15 Jan, Matthias Schniedermeyer wrote:
>>>
>>>
>>>
>>>> Stefan Richter wrote:
>>>>
>>>>
>>>>
>>>>> On 14 Jan, Richard Knutsson wrote:
>>>>>
>>>>>
>>>>>
>>>>>> (Really liked the idea to have a "Maintainer"-button next to "Help"
>>>>>> in *config)
>>>>>>
>>>>>>
>>>>> Rhetorical question: What will this button be used for?
>>>>>
>>>>>
>>>> Having "all(tm)" information of something in one place?
>>>>
>>>>
>>> Or, "click here to say 'it does not work'"?
>>>
>>> My rhetorical question wasn't about what it is intended for, but what
>>> people would think it was intended for if it was there.
>>>
>>>
>>>
>> I think it could be practical to have an easy access to whom is
>> responsible for a driver and which mailinglist its development is
>> addressed to, both for people interested in helping develop the driver
>> and those who got an error (or fan-mail :).
>>
>>
>>>> I think adding the Maintainers-data is more or less a logical next step.
>>>>
>>>> It's not always clear from the MAINTAINERS-file who is the right person
>>>> for what. Especially as it is a rather large text-file with only
>>>> mediocre search-friendlieness. It's a 3.5 K-lines file!
>>>>
>>>> So when you know that you have a problem with drivers X, wouldn't it be
>>>> great if you could just "go to" the driver in *config and see not only
>>>> the Help-Text but the Maintainers-Data also.
>>>>
>>>>
>>> Seems more like what you actually want to have there is links to users'
>>> mailinglists or forums.
>>>
>>> When this thread started, it was about assisting authors in submitting
>>> patches.
>>>
>>>
>>>
>> Yes, this is a bit out of scope, but just realized a simple way to
>> implement it if using the CONFIG_FLAG-approach, just "grep" after the
>> flag, under which the user hit the "Maintainer"-button, in the
>> MAINTAINER-file. Also, I think this solves the handler-problem since an
>> entry can have multiple CONFIG_FLAG's stated.
>>
>> I don't think we should add the maintainer-entries directly in Kconfig,
>> as you Stefan stated, because it is for configure the kernel. With the
>> above approach, it will just require minor fixes in the "make *config"
>> to handle it.
>>
>
> But how do you suppose the user gets the CONFIG_-String, which the user
> then could for searching?
>
> I'd say only a small percentage of hardcore-users would use the
> .config-file directly, the others would deviate over *config, so i'd say
> if the MAINTAINERS-data is integrated into Kconfig it's the perfect(tm)
> 90% solution.
>
> OTOH you could just teach the *config to lookup a MAINTAINERS-entry when
> all they are properly flagged.
>
Oh no, did'n mean like that. All entries in the Kconfig has a "config
CONFIG_FLAG" (of course ;) ) and so *config "knows" which flag to search
for (if added to MAINTAINERS, that is).
> On Sat, 13 Jan 2007 17:30:39 +0100 Richard Knutsson <[email protected]> wrote:
> Would like to come with a suggestion I have been wondering about for a
> while, why not add the config-flag, used in Kconfig/Makefile in the
> MAINTAINERS-file?
I find that the most practical way to find out who really maintains a
driver is to run git-whatchanged on it and see who has been doing stuff to
it.