> I wrote PT_SYSCALL stuff for the SPARC and posted it to current-users
> _and_ sent it directly to deraadt...and as of the latest sup I have,
> all that's happened is that he's committed my ptrace(2) manpage, which
> describes it (and an old version of it, at that, even though I sent him
> the latest ptrace.2 along with the PT_SYSCALL patches).  The code
> itself isn't there.

I saw this, haven't even had time to look into it yet.

> I've also noticed that my patch to gcc for -Wformat versus %qd was only
> partially applied (or perhaps was not actually applied, but recreated
> by someone else basd on my patch); in particular, for some reason the
> pedwarn call and its controlling if were skipped, so that -ansi
> -pedantic won't see anything wrong with the (non-ANSI) %qd.

i didn't even _see_ this patch...

> I wrote a replacement libcrypt that does reasonably secure password
> hashing in an exportable manner, and that's compatible with old hashed
> passwords if you have DES-based hashing code available to boot.  I
> posted about its availability (may even have posted the code, I'd have
> to check archives to be sure) to current-users and heard nary a peep of
> interest.

nor this one.

> I added an option for modifying the NFS mount options used when
> mounting the root when booting diskless.  Nobody expressed any
> interest.  Perhaps I'm the only person who cares....

i didn't see this, either.  however, there's a way to do this
as a kernel compile option, and it should be doable at mount -u time,
as well.

> I added an option so the SPARC console terminal emulator comes up in
> white-on-black mode.  deraadt flatly refused to have anything to do
> with it, telling me there was no need for it (presumably meaning he had
> no need for it, ignoring the need I clearly must have had in order to
> have been prompted to do it) and that it would add too much maintenance
> complexity (the patch simply adds five lines: one blank, one #ifdef,
> one #endif, and two lifted directly from the switch-to-white-on-black
> code in the emulator).

this is a port-specific thing.  a port's 'owner' is really the final
arbiter of taste and fashion about stuff to go into that port.
I can't see why you'd need to make this a kernel option, in any case.
(it seems to me that there are other ways to do it that are more
appropriate.  adding kernel options to #ifdef 2 lines of code are
hardly ever appropriate.)



chris