I would suggest the following, perhaps obvious, cautions.

     o 	It really should have its own SMP-safe lock calls, but it doesn't.
	I.e., it requires biglock, and it seems like new code in critical
	kernel areas like this should not.

	Let's not dig the hole we are in deeper, OK?

     o	Finish UVM integration

     o	Things like, e.g.,  LIMITBIGPIPES should be done another way,
	at a minimum it should be:
		int limitbigpipes = LIMITBIGPIPES;

	Ideas that might be better would be: sysctl(8), runtime computation
	based on RAM size, adaptive adjustment based on errors, well, anything
	except what it is now. And if we must have a #define, perhaps it
	should be in machine/param.h.  (Don't forget conf/param.c as a place
	to put switches and knobs.)

I think the above stuff should be done before commit, not after.

I have at least one concern about the wisdom of this entire approach.

    o   Because this hooks into the system at the kernel descriptor level,
	i.e., the outermost possible layer, it needs to implement every
	little semantic someone might expect of pipes, as well as do
	its own SMP locks, as it adds an entire third I/O type to the
	previous choice of merely: vnode or socket.

	One other way is to go thru the vnode layer, VOP_WRITE() et al.
	This gets you SMP locks, kernel I/O on pipes (dunno what that's
	good for, but hey) and it avoids adding another dimension to the
	already weird area of "socket I/O != vnode I/O", which has caused
	us trouble in the past.

	So, although it's a very BSD thing, it's kind of annoying already
	that sockets are parallel to vnodes. Things would be better if
	they also hooked in underneath, and we had ONE type of I/O,
	not two, and now maybe three.

	Another reason to hook in under the vnode (or socket) layer would
	be if you had another type of stream that the optimized pipe code
	would work for. As proposed, that can never happen.

//ross