Date: Wed, 15 Nov 1995 10:19:27 +0100 From: Poul-Henning Kamp <phk@critter.tfs.com> To: Peter Wemm <peter@jhome.dialix.com> Cc: Bruce Evans <bde@zeta.org.au>, CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/kern kern_sysctl.c Message-ID: <2525.816427167@critter.tfs.com> In-Reply-To: Your message of "Wed, 15 Nov 1995 12:51:02 %2B0800." <Pine.BSF.3.91.951115124212.309I-100000@jhome.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hmm. Poul-Henning has used a useracc(new, newlen, B_READ) before going > into the sysctl handlers. I thought this was sufficient to be reasonably > sure that accidents aren't going to happen? Actually, I still lack one feature, which I deliberatly have held back on. The old implementation would lock the (old,oldlen) so that it could do the copyout without a context-switch. In all cases but kern.vnode. I really hate that exception, but on the other hand I'm not sure I really think we should have that feature anyway. It's going to be quite an effort to implement atomicity on a SMP system, and I really don't think it is the right way to solve the problem. I can see that it's a lot easier in the user-land, but boy is it a mess in the kernel. Now, we can agree that the sysctl system call is badly designed. It lacks a get-next, it lacks a "flags" or something similar for controlling a feature like this... I'm not too keen on making yet a new syscall, but it may be the right thing to do nonetheless. The alternative is to use a oid-prefix: 0.1.<oid> Get/Set with locked user-land buffers 0.2.<oid> GetNext 0.3.<oid> GetInfo, returns name & type info on <oid> 0.4 GetBulk, "new" is a list of OID's, get them all into "old". (needs some packing rules) Another thing I would love to make is a ability to create variables for user-land purposes: 0.5.<oid> Create a variable, "new" holds info. This would allow us to use sysctl as a miniature registry for information, for instance: domainname which crypt to use as default. what to do in malloc in case of an allocation error. anything else you can thing off... What do you people think ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2525.816427167>