From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Patches.. (Was re: <none>) Date: 30 Jun 1992 21:02:16 GMT
In article <1992Jun30.155048.6563@spuddy.uucp> sweh@spuddy.uucp (Stephen Harris) writes:
>
>However, the problem I forsee with projects like this is a lack of
>(i) co-oridnation
>(ii) quality control
Indeed. I try to keep both these going, but it's not exactly easy. The
biggest problems are (a) features that I haven't used too much before
(and thus don't know the exact semantics), (b) hardware peculiarities or
simply hardware I don't have and finally (c) lack of infinite time and
energy. (a) can result in some weird behaviour (like the pty change in
pl2) while (b) results in code I cannot check. (c) is pretty obvious :)
>I'm sure Linus would hate to have to rigorously check EVERY patch that
>goes to him - he'd never have any time to program himself :-)
Most of the patches I get and apply are quite thoroughly checked by me
both by reading the actual cdiffs (which is why I often insist on diffs
instead of new files even if the diff is about the same size) and by
then reading and possibly modifying the code. And several patches
either aren't used or are heavily modified.
The biggest patch that I didn't check is the SCSI drivers: it's
essentially useless to wade through code when you can't change it anyway
for being afraid you break something. It shows pretty well in the
sources too: the scsi drivers look quite different from the rest of the
kernel.
Most other patches have gone through pretty rigorous checking: some have
looked definitely different after I have had my way with them. So, if
you do kernel patches, and want them included in a future release, here
are a few points that can make it go faster:
- mail it to me. If it's more than a couple of hundred of lines of
compressed uuencoded patches, you had better talk with me about it
first: patching more than that is definitely not something I like to do
without a very good reason. I won't fetch patches from ftp-sites unless
there is some good reason for it.
- do it in small separate parts. If you fix a lot of things, send
several small patches rather than one big one. That way I can (a) more
easily see what the patch does, and (b) select and edit the patches more
easily.
- follow the same programming style as the rest of the kernel (not
counting the scsi drivers). That means tabs and the normal linux brace
placing. If I like the look of the code, it's easier for me to follow
and I'm definitely not above disliking a patch just for visual reasons.
Even when the above holds true, I might not patch it in for several
reasons:
- If I don't like the way something is implemented, I usually skip it
completely, or then I might write my own version if I find it an
interesting and useful patch. Not liking it can be due to several
reasons: bad special case checking, bad coding style, weird and long
functions and uncomprehensible algorithms. Or any number of things.
- hardware reasons: if I don't have the hardware I'm less likely to
patch it in. The scsi drivers went in because they were obviously
needed (and didn't clutter the rest of the kernel). This is definitely
why I still haven't looked at the ethernet patches nor the bus-mouse
driver: both might be vital to some, but...
- if I'm busy with other things or the patch doesn't go in cleanly due
to other patches, I might just forget about it and hope the patcher
makes a new version for the next release. Some patches have had to wait
for several releases until I implemented them.
- simply because I don't feel it's important enough. Bug-fixes and
important fundamental new features definitely get priority, as well as
some things I simply consider interesting.
- they don't fit well with something I've been thinking of doing. This
goes for the VM86 patch: it's an interesting concept, but to make it go
in cleanly I'll have to re-write the mm a bit first. The current mm
patches for VM86 are something of a hack, and might make it difficult to
correct the mm later. And while VM86 is good, a clean mm is more
important right now.
The result of all this is that if you want a patch to go in, you have to
(a) tell me about it (b) make me understand that it's really nifty (the
itimers patch went in the day I noticed xneko wanted them :-) (c) do it
cleanly: linux is a hackers kernel, but that definitely doesn't mean
ugly hacks are encouraged (d) tell me about it some more. If you feel
something needs bigger changes (like the msdos filesystem needing 32-bit
inode numbers), it's a better bet to mail me and ask about it, and I
might do it myself just because I feel better about it after that.
Also note that the fact that I don't use it doesn't really matter: some
patches are quite useable just as patches. Or as complete systems from
somebody else than me: if somebody thinks a linux system with
"unofficial" patches would be useful, it's certainly a good idea.
Several packages have come with kernel patches just because the standard
kernel didn't support them (the original X and ps095 both had kernel
patches in the distribution to add the necessary features.)
Linus