On 13 Jan, Richard Knutsson wrote:Hmm, how are those drivers built? Can you please point me to one?
[...]
SUPERCOOL ALPHA CARD[...]
P: Clark Kent
M: superman@xxxxxxxxxx
L: some@xxxxxxxxx
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?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 sourceCan you make a object-file out of 2 c-files? Using Makefile?
files. Diffstats show source files.
Example: The sbp2 driver is an IEEE 1394 driver and a SCSI driver.The one listed for CONFIG_IEEE1394_SBP2 :)
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 mailinglistsWell, as they say: "If it is too good to be true, it usually is" (but I don't think it is too far fetched)
sounds to me like a desirable feature, not just from the point of view
of submitters but also of maintainers.