From owner-freebsd-hackers@freebsd.org Fri Jul 29 16:05:43 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 700E8BA8C55 for ; Fri, 29 Jul 2016 16:05:43 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com [209.85.214.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42C6B1956 for ; Fri, 29 Jul 2016 16:05:42 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f42.google.com with SMTP id f6so112039007ith.0 for ; Fri, 29 Jul 2016 09:05:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=iOg9itSckkx4+635eV66zoiN4cM9yYgnWkOhCoxkVjA=; b=PNiQo5codMTlIgnHHMeY8HcpSqWY66tCI6YrqyrmV5m3neu6bhYQRLnzHYL3BZGera PnpRi3J2kmc0Ik1wcMmQDDxkYw1rhqt7mt2aG8xMkvYNo6IBF+hNOfsBQ7gH1PgAzmjN b2dzZgo5YvgiPpKbBmTosTSibjJSOtWD9frzc/GEQwBhGLuv47ivc7pepyOj1lOQLeCB YbwKnA3aEFdAyczqc4bjp8a08g7JWwdpJpl9O0PoOJxlmnAQnmDOmMkcXg5rqxH4bLLU c9nrTWdxpuEzhVnJjZr23tkM5LyHesw5gyrH1ak4QTDY+ZSeXlSCQdwEWW3xwUtiQNb+ J2Bg== X-Gm-Message-State: AEkoouuClh927NFm8Jvbv452K73lmxfbkO5OP49Cw6P9x2DLsIqGuS2VnKNqLf8vm2tVDA== X-Received: by 10.36.209.130 with SMTP id w124mr2139692itg.2.1469808336033; Fri, 29 Jul 2016 09:05:36 -0700 (PDT) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com. [209.85.223.171]) by smtp.gmail.com with ESMTPSA id 97sm7447925ioi.12.2016.07.29.09.05.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jul 2016 09:05:35 -0700 (PDT) Received: by mail-io0-f171.google.com with SMTP id m101so132659312ioi.2 for ; Fri, 29 Jul 2016 09:05:35 -0700 (PDT) X-Received: by 10.107.56.70 with SMTP id f67mr46768817ioa.162.1469808335597; Fri, 29 Jul 2016 09:05:35 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.36.233.67 with HTTP; Fri, 29 Jul 2016 09:05:35 -0700 (PDT) In-Reply-To: References: From: Conrad Meyer Date: Fri, 29 Jul 2016 09:05:35 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Modify user space from kernel. To: Adam Starak Cc: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 16:05:43 -0000 On Fri, Jul 29, 2016 at 6:11 AM, Adam Starak wrote: > Hello! > > 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= . > > 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 fro= m > kernel to user space without knowing the size of it? > > Right now, the implementation of __sysctl() function requests void pointe= r > 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= . Hey Adam, That is the usual way to do it. Just curious =E2=80=94 why do you want to avoid that situation? Your other option might be to put an upper limit on the size of the result, and pass a buffer of that size in from userspace. But then you are artificially limited to some arbitrary size and must preallocate a large buffer even in the case that the output is small. Best, Conrad