On Wed, Jun 28, 2000 at 12:11:30AM +1000, Simon Burge wrote:
> erh@nimenees.com wrote:
> > 	This is a bit delayed, and I'm probably sounding like a broken
> > record, but each time someone mentions this I'm liking the special 
> > socket type idea more and more.
> 
> Ok, I'm mostly ignorant of the socket idea - so you open a socket, set
> some particular socket option read back the data, right?  Doesn't this
> mean that the complete reply needs to be buffered in the kernel?  Take
> the kern.proc sysctl case - you copyout as much data as requested and
> you're finished, nothing left for a later syscall to finish handling.
	Well, you could buffer it, but why?  We could just have socreate()
put something other that a function pointer to soreceive() in for so_receive
and have that function create the data at the time of the read.
	Or perhaps, since this will be a new address family with a
new protosw table and it's own usrreq function, we can have _that_ set up
any special function pointers.  That might actually work better since
it would have less imapact on the general socket code.

> Am I missing something, or is the socket approach not suited to large
> amounts of data transfer?
	uh.. last I checked sockets worked just fine for that.  ftp doesn't
seem to have problems using them to transfer many megs of info.

eric