Date: Sat, 15 Aug 1998 23:09:02 +0200 (MET DST) From: Willem Jan Withagen <wjw@surf.IAE.nl> To: tlambert@primenet.com (Terry Lambert) Cc: mike@smith.net.au, wjw@IAEhv.nl, hackers@FreeBSD.ORG Subject: Re: Adding system calls Message-ID: <199808152109.XAA05502@surf.IAE.nl> In-Reply-To: <199808152041.NAA21190@usr01.primenet.com> from Terry Lambert at "Aug 15, 98 08:41:51 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
You ( Terry Lambert ) write: => > > 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. I'd like to migrate my system in such a way that it keeps functioning as much as possible. That means that if there are possibilities to work around existing/working subsystems, that's my way of preference. In the end I'll provide code which should provide a migration with a little pain as possible. This case has the MUX-call to libc, which is easy to mimmic. But then getting all the MACRO-created stuff merged, that is more of a pain. => 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. Yes, that is the part I understand. But what about the other issues. You'd like me to "cramp" everything into this omni-potent parameterlist. Or is this the answer below? I do not understand the technical text, whilest I'm able to read the english. :-( => 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. => 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-). Numbers?? This is why I asked about a "list" of things to concern myself with! If the callgate overhead is humongous, then I'll skip some of the "optimisations" I had in mind. => > > => 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. So what about getting/returning my sysctl-mibs? Mike Smith has argued to completely go the text way. (but they are no FS-paths). Currently SNMP is strings/arrays with numbers. Currently I take arrays of integers (could call that a sort of string), or an arrays of strings. Which could be turned into an array of point-concatenated strings, if it makes life easier to get the data. --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. 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?199808152109.XAA05502>