Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Jan 1999 11:40:32 +0100
From:      Marcel Moolenaar <marcel@scc.nl>
To:        Brian Feldman <green@unixhelp.org>
Cc:        Mike Smith <mike@smith.net.au>, freebsd-emulation@FreeBSD.ORG
Subject:   Re: sendmsg() not working?!
Message-ID:  <369DC9A0.F1413964@scc.nl>
References:  <Pine.BSF.4.05.9901121537540.2373-100000@janus.syracuse.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

marcel

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?369DC9A0.F1413964>