> How does one go about doing this? I used to do a lot of kernel-hacking
> back in the early '80s, and have provided the odd patch here and there,
> but I don't do politics well and developed the sense that Linux was sort
> of divided up into fiefdoms and that I had little chance of getting stuff
> into the kernel.
My approach is to find something that I like and think is important,
and that no one is actively working on. For me, that is Makefile
and configuration stuff. I got involved in drivers/sound because I
wanted to clean up drivers/sound/Makefile.
I also spend significant time proof-reading and testing other people's
patches. That's because I expect other people to step up and proof-read
and test mine, as described in the top-level MAINTAINERS file. Catching
bugs earlier is cheaper than catching them later.
> I've offered to touch up the readme.modules (several times) but have
> gotten no response.
I think it would be an excellent thing to rewrite the morass of
drivers/sound/Readme files. I'd volunteer to proof-read the result.
> My suggestions about the module stuff would either have to be
> backwards-compatible or would require touch-ups to every modular driver;
> in either case I would be hesitant to wade into it without a go-ahead
> from those who own those areas of code.
Alan Cox is the owner of the sound code -- if you ask him a specific
question he will give you a specific answer. For what it's worth,
I think it would be good thing for Config.in to provide a facility for
specifying defaults that could be overridden at module installation
time.
Regards,
Michael Chastain
<mailto:mec@shout.net>
"love without fear"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu