Date: Sat, 15 Aug 1998 10:11:26 +0000 From: Mike Smith <mike@smith.net.au> To: wjw@IAEhv.nl Cc: mike@smith.net.au (Mike Smith), hackers@FreeBSD.ORG Subject: Re: Adding system calls Message-ID: <199808151011.KAA00653@word.smith.net.au> In-Reply-To: Your message of "Sat, 15 Aug 1998 12:28:58 %2B0200." <199808151028.MAA20095@surf.IAE.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
> You ( Mike Smith ) write: > => > > => > What/were is the receipe to add new system calls. > => > I'd like to add my own sysctl_* calls. > => > => You don't feel that you can overload the current calls? > > 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. > And there are structures for the new functionality which I cannot get into > the original call without making it a real mess. I consider the current > implementation already warped. (appologies to phk) Poul didn't invent it, just made it more useful. > => > Are there any directives on what "design" to use while defining these calls. > => > Like: > => > - Use only one syscall as a multiplexer > => > (Which created a not so trivial mess is the current sysctl) > => > => This is good if all the subcalls share similar data. > > Well think about this one: > sysctl_node *sysctl_getnext( sysctl_node *node); > > It allows you to give a kernel pointer, and gets you a pointer to a next > structure. > > Would this be a sensible move? It's easy but will allow invallid accesses to > memory, if somebody uses garbage as pointer. No, it's an extremely bad move unless it can validate its argument. > It is a little faster, since it doesn't have to find the starting point, but > that doesn't outweigh the disavantage. Correct. The 'correct' way to implement the above would be: char *sysctl_next(const char *name); where the return value would be a malloc()ed buffer containing the name of the next node, or NULL on error. Errno would be set to EINVAL if (name) did not exist, or ENOENT if there was no next node. You would use your hashtable to locate (name), and then pick the next node. If (name) had been deleted, you would have to perform a best-guess search. Keeping nodes sorted by name would trivialise this. > => > - What parameters are a bad idea to transfer from > => > user to kernel space? > => > => Just the ones you need. > > Well, kernel-pointers are perhaps an issue. > And or structures with kernel-pointers. None of these should ever be exposed. > => > And answers to questions like: > => > - Where can I find the "user"-data > => > => Such as? > > I'm still trying to parse the code which does something called > "userland_sysctl", which I thing does a lookup in userland data?? No, it just handles sysctl calls where the data portion may be in user space. > > => > - Hoe to I return results for "call-by-ref" parameters > => > => 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. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199808151011.KAA00653>