Re: Hurd's defpager and memory leak bugs

[Roland McGrath]

> Is Hurd's `defpager' used at all? 

No.

> Is it even compiled while building the Hurd?

Why don't you know this from personal experience?

> [hurd]/defpager/defpager.c
> contains a blatant bug that should not even compile. But if `defpager'
> completely ignored, that could be ignored as well.

It doesn't hurt to fix this code, but it has never been used and will not
be used in the foreseeable future (the eventual future, but not the
foreseeable future).

> Also, I took a look at the current Hurd source tree and noticed that
> a lot of the fixes for null-from-malloc or no-free-after-malloc
> type bugs that I posted a while ago. I remember there were some
> concerns about propagation of error in certain situations. I can
> look through these fixes again and make sure that reported errors
> are propagated properly, etc. Also I can repost them in smaller
> batches so it would be easier to review them. How many do you want,
> a dozen, two dozen at a time?

These kinds of code audits are always welcome.
We always want to improve the robustness.

If you change the interfaces of any global functions (including library
interfaces), then each interface change and all the changes to affected
code should be grouped as one patch separate from others.  That way I can
easily apply your other patches while leaving out the ones involving the
interface change if I have some reservation about it.

If all your changes are trivial and essentially the same change in each
spot (even if there are many of them), then those can all go together in
one big patch.  The ChangeLogs are per-directory so you need to repeat the
log comment in each directory.  For this kind of change where the log entry
is not interesting, you can just include the ChangeLog patches in a big
patch done with -r so I can apply the whole thing at once.  (Normally we
like you to just include the ChangeLog fragments without diff marks
prepended to the patch in your email.)

If you make two different flavors of pervasive simple changes then send
separate large patches for each flavor of change.

These guidelines are not ironclad.  The point of it all is that a
maintainer will most often either apply the whole patch you emailed or
reject it with some complaint about how you did something.  (It's all about
the laziness of the average maintainer, and me and Thomas add up to way
lazier than you will get around to shaking any sticks at.)  So if it is
easy to apply one change I do like without also applying another change I
might want done slightly differently, then I will apply the first change
immediately and you'll only have to wait and haggle for the second part.
If it's hard (read: requires more than three keystrokes) to apply just part
of your patch, I'm liable to just reject it and do nothing at all until you
send me something I can apply easily and be happy with.