Subject: Re: Replacing the sysctl() interface.
To: Simon Burge <email@example.com>
From: None <firstname.lastname@example.org>
Date: 06/27/2000 19:53:33
On Wed, Jun 28, 2000 at 12:11:30AM +1000, Simon Burge wrote:
> email@example.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.