Date: Sat, 15 Aug 1998 20:41:51 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) Cc: wjw@IAEhv.nl, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: Adding system calls Message-ID: <199808152041.NAA21190@usr01.primenet.com> In-Reply-To: <199808151011.KAA00653@word.smith.net.au> from "Mike Smith" at Aug 15, 98 10:11:26 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Well I'd like to make a nsysctl call for starters, just to able to leave > > everything in place, and add my own version in parallel. This would make the > > migration a lot simpler: I don't have to take care of all kinds of pitfalls > > which pop up due to unforseen loop-holes. > > Fair enough, especially for testing. But not for cutover. The sysctl(3) code uses a multiplexed system call; the new code can be multiplexed off the old system call entry without introducing and backward incompatabilities to current sysctl using code. It may (but probably won't) help you to multiplex at the call level rather than the parameter level. It would be very easy to pass in a NULL pointer for ctl_name, ans use that to set up a seperate mux in the system call itself. Meanwhile, looking into this, I was alarmed to find that kld was not using a multiplex entry point. 8-(. People, these things are not performance sensitive; this is not "read" we are talking about here, and these things are not interacting to provide a bottleneck over a large number of iterations while doing something else. You are unlikely to see sysctl speed as one of the things tested in lmbench. If it becomes an issue, you can argue for why a switch statement is a significant fraction of trap or call gate overhead. 8-). > > => Use copyin/copyout and the fu*/su* calls, all of which have manpages in > > => -current. > > > > Oke, I have some current-version on my disk. I'll put it at the end of my > > MANPATH. But then I'd still need some happy guesses as to their names. > > copyin, copyout, fubyte, subyte. Note that copying in or out strings is an inherenetly bad idea, unless those strings represent a filesystem path name. I've long commiserated over the fact that the NFS subsystem uses copyinstr. Linux actually has the right idea (although it resulted in a memory leak in a lookup failure case, until I corrected it for them ;-)) where they have a single string routine, usable solely to obtain a user space path buffer in kernel space. Of course, their use of address space preverification for copyin/out makes some of their code faster, but with kernel threads, they now have the problem of a race wherein one thread preverifies and blocks, and a second thread modified the address space out from under the first, and they copyin/out from/to "the noplace". So do what they do, but not how they do it. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808152041.NAA21190>