Date: Thu, 14 Jan 1999 16:48:22 -0500 (EST) From: Brian Feldman <green@unixhelp.org> To: Marcel Moolenaar <marcel@scc.nl> Cc: Mike Smith <mike@smith.net.au>, freebsd-emulation@FreeBSD.ORG Subject: Re: sendmsg() not working?! Message-ID: <Pine.BSF.4.05.9901141639390.26759-100000@janus.syracuse.net> In-Reply-To: <369DC9A0.F1413964@scc.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 14 Jan 1999, Marcel Moolenaar wrote:
> Brian Feldman wrote:
> >
> > On Mon, 11 Jan 1999, Marcel Moolenaar wrote:
> >
> > > Mike Smith wrote:
> > > > >
> > > > > The patch Brian posted does do the job, but, IMHO, is not a good basis for
> > > > > further finetuning of the sendmsg and recvmsg syscalls. Especially the
> > > > > copyout bothers me. Is it worth reimplementing sendmsg and recvmsg or is
> > > > > everybody happy with the patch?
> > > > > > That depends on how you describe "reimplementing". You might want to
> > > > shim the generic implementations to make them more friendly to the
> > > > Linux layer, but I would not think that reimplementing the bulk of the
> > > > syscall in the Linux emulator would be a wise idea.
> > >
> > > If sendit and recvit in /sys/kern/uipc_syscalls.c would be public, than we
> > > could create a linux_sendmsg and linux_recvmsg based on sendmsg and recvmsg
> > > and have it call sendit and recvit directly.
> > >
> > > To eliminate the copyout and also to prevent a copyin of the, possibly large,
> > > control message (ancillary data) it would be benificial to seperate the cmsg
> > > header from the cmsg data in the lower layers (at least for sending).
> > >
> > > The only thing that's against such a modification is the impact on the
> > > existing code. I'm willing to make the modifications, only if there is a
> > > change that such a change would be accepted in the first place.
> > >
> >
> > What Linux syscalls aren't working properly (socket calls, of course)?
>
> Why do you ask?
>
> > This is the only one I've _ever_ run across. And I hardly think a 4-byte-copyin,
> > then a conditional 4-byte-more copyin, and then conditionally again a 4-byte
> > copyout is substantial overhead!
>
> But some overhead can be eliminated if you integrate the functionality of
> sendmsg and recvmsg (the FreeBSD native syscalls). If we all believe sendmsg
> and recvmsg (in the Linux emulator) work, than I think it's a good time to
> discuss possibly optimizations (be it in overhead or in
> maintainability/readability)
>
> > You know of course that system call arguments are faulted in from the user
> > stack on int 0x80, so it doesn't change the system call time that much
> > (read: substantially at all) to have a couple more.
>
> Ok; but the copyout changes data in a structure controlled by the program.
> That change is visible by the program. Technically speaking, the Linux
> emulator can change runtime behavior. I know; it is not likely, but possible.
> That's what bothers me about the copyout.
I suppose you're right, I saw the const struct msghdr * in sednmsg, but I don't
think that necessarily applies to the cmsg, which is just a pointer in msghdr.
We do not make any changes to the const struct msghdr *, so we violate no
rules. Why would a program ever check if the sendmsg affected cmsghdr? All
it would do from then on is have the corrct value of cmsg_level. If it
really bothers anyone any serious amount, there's an easy fix. Change the code
to
if ((oldval = copyin(blah blah blah) == 1){
if (error = copyout(SOL_SOCKET var blah))
return error;
error = sendmsg(blahblah);
copyout(&oldval blah blah);
return error;
}
pardon the crappily horrible code style, I'm not actually submitting this kinda
thing into the kernel.
>
> marcel
>
Brian Feldman _ __ ___ ___ ___
green@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ ____ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ ____ _____ |___/___/___/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-emulation" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9901141639390.26759-100000>