Re: CVS commit: src/sys/dev/pci

[Thor Lancelot Simon <tls%netbsd.org@localhost>]

On Thu, Oct 30, 2008 at 10:58:34PM +0100, Bernd Ernesti wrote:
> 
> I'm a little scared to see such a big new and unknown type driver
> going in now.

We specifically asked core whether it was acceptable to check in a new
device driver for this device now and were told yes.  We've spent literally
months trying to get permission to open-source the driver and finally got it
on Monday -- thus the late checkin.  I'm sorry for the surprising appearance
of many new files this caused; we've been working to avoid such a last minute
commit for months, but didn't succeed.

This is the driver for the device we used to design and test the new
multiple-request and asynchronous features we added to /dev/crypto some
months ago.  Without it in the tree, there's no example for other device
authors and also no way to test the async asymmetric operations (the
cryptosoft backend does not do asym crypto) so I think it is actually
important to ship it with 5.0.

But more generally, I don't understand why you find this "scary".  What is
there to be scared of?  If you don't have the device, the driver cannot
possibly cause you any trouble, which is, I assume, why core said that
unlioke other commits, a new driver at this stage in the release process
was OK.  If you _do_ have the device, you could not use it before (there
was no NetBSD driver) so this can only be helpful.

Similarly, since this commit does not actually patch any existing code, I
have to say that I regard the separate comment that the "patch" should have
been sent to tech-kern for review as somewhat off the mark.  But more
importantly, though core said we could commit before the branch or after
and then pull-up, we wanted to avoid the work for releng of pulling up so
many files, and keep the CVS history a little cleaner.  Darran worked very
hard to get this ready on short notice and I at least am grateful that he
did so.

Thank you for pointing out the pcidevs problem.  Also, we forgot to cvs add
the manual page.  I will check that in later today and request a pullup.

Finally, I should say I'm very glad NBMK, who own this driver and its
associated docs, let us open-source it.  The device is old but surprisingly
capable and the driver, docs, and their patched openssl (which we did not
check into NetBSD but are working to make available under a reasonable
license) provide a wealth of examples of how to run fast with modern crypto
accellerators -- chips that can do more than just bulk encryption and hash.
There is no other open-source support for anything like that except for one
dead branch of Linux kernel crypto code, which supports only IPsec, not SSL
record or handshake operations.  This chip does much more than that and we
have driver and SDK code -- and docs -- available to work with.  They have
done a very very good thing for crypto support in NetBSD.

Thor