Date: Sat, 30 Jul 2016 23:32:24 +0000 From: Brooks Davis <brooks@freebsd.org> To: Adam Starak <starak.adam@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Modify user space from kernel. Message-ID: <20160730233224.GB98042@spindle.one-eyed-alien.net> In-Reply-To: <CAAz%2B7vqLgd5GSBfFMdD-xsAsEoujgPh8ZdKY4xZ1LO0h30OmSQ@mail.gmail.com> References: <CAAz%2B7vqLgd5GSBfFMdD-xsAsEoujgPh8ZdKY4xZ1LO0h30OmSQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 29, 2016 at 03:11:25PM +0200, Adam Starak wrote: > Hello! >=20 > My name is Adam. I participate in Google Summer of Code this year. I came > up with a big problem, which doesn't allow me to go further in my project. >=20 > I made a new syscall, which is going to retrieve sysctl data and put it > inside the nvlist. And here my problem is. I need to move somehow this da= ta > (packed nvlist) into the user space. Is there any chance to pass data from > kernel to user space without knowing the size of it? >=20 > Right now, the implementation of __sysctl() function requests void pointer > and size in order to get data. If allocated memory is too low, it returns > ENOMEM and you need to realloc the data. I wanted to avoid this situation. If you want a memory based interface, that is what how it should be. If the size won't change, then you can output the required size on failure. For example, if your syscall has a definition like: int give_me_an_nvlist(void *buf, size_t *buflen); On ENOMEM you'd write the required size to buflen. If the list really don't change size, requiring two system calls would be a lot cheaper and easier to handle than a socket as someone else proposed. -- Brooks P.S. Purely as an FYI, there is technically another option. You could inject a set of page mappings into the process, write the nvlist to them, and then return a pointer to them. This would be fragile, prone to hard to diagnose memory leaks, and would probably break all sorts of tools like valgrind, but it's theoretically possible. I seriously doubt such an interface would be acceptable to the project. --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXnTkHAAoJEKzQXbSebgfAuzYH/1qM5Mt3c8ipz3GSmajtWWpl U26v7nQhFSMujDFvcJSickWGYuBmMjt+SCkVjOCafY11iQ+9aCSLCKsmwSnp8JJh DeIDJKV3icD7Owx9STkRW3Uw0n5PaFjp15LVWsZI6EraBN5JUPIZTxJUcfksp/gA +UBg2kW5oqzh1BisIOf+I3kxVVNJHO8H0g9wTBul5siSJ/hsdDdijYHPspm2X50/ HBDNuEtwv4xENtuwa4ZXn6Y26smtwTH0wJ6dvI+rrDONIIgIeWgamvm0E6UbhYng 7A2Bzgr+lvLVYkVyi6MngUgSQNFXM4ulfErx3OUIgARCxJwyjkl2Yl0XoQXR4n0= =LnlL -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160730233224.GB98042>