From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 04:43:54 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7369424C for ; Sun, 15 Feb 2015 04:43:54 +0000 (UTC) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (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 468A86CD for ; Sun, 15 Feb 2015 04:43:54 +0000 (UTC) Received: by pdjy10 with SMTP id y10so27819794pdj.13 for ; Sat, 14 Feb 2015 20:43:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:content-transfer-encoding:message-id:date :subject:from:in-reply-to:references:to:cc; bh=FuHX+WukOjXKWF7CWMD8mm+YhcerODQB8X7vDAdWDnw=; b=AeFUhTe5xGOXBgUCUjSHYBO6KxqIjxstHdgAcqk5SXE2zcVAhImqP59sStBBuVCzP1 wXopiojDB1b8sSyFlRbf7moGH64L/Esho9ggc7zIIYKnobRkfkRBYxWhRM28IMgaTpzQ R5WyAD5v/rpJTLHOpvMbkvsLecPX3hPpVJxXLmvKUlxu+9sHOridlx9m6eBfJ73qJTzJ vJx9Rdz/gpZkVe1xHnlFCT6F8GEybKpm+ejAr3g1mizuivi04yN9c9NDyzHQ6xpVjyNl jNpmwEtoTWXO5WbZUD//dP48Izk3jNkczrLV8ABMuoUg861V6fS/1yIHdCZ2Nc27NNVl Fnaw== X-Received: by 10.70.27.33 with SMTP id q1mr29064817pdg.84.1423975433226; Sat, 14 Feb 2015 20:43:53 -0800 (PST) Received: from [127.0.0.1] ([39.249.67.238]) by mx.google.com with ESMTPSA id ki2sm10890330pdb.33.2015.02.14.20.43.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Feb 2015 20:43:52 -0800 (PST) Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.2.1.3442) Message-ID: <20150215044351.5988497.50786.18252@gmail.com> Date: Sun, 15 Feb 2015 11:43:51 +0700 Subject: Re: Suggestions for communication between FreeBSD user-space and kernel modules From: dmaryanto@gmail.com In-Reply-To: References: To: Ryan Stone , Yue Chen Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 04:43:54 -0000 ---- tail -f /var/log/travel.log http://arungi.selatsunda.co.id =A0 Original Message =A0 From: Ryan Stone Sent: Minggu, 15 Februari 2015 09.54 To: Yue Chen Cc: freebsd-hackers@freebsd.org Subject: Re: Suggestions for communication between FreeBSD user-space and k= ernel modules The two main interfaces for passing data between userland and the kernel in FreeBSD are syctls and ioctls (there are others but their use is rather specialized). sysctls are typically the simplest to set up, but aren't well suited for passing around complex structured data. sysctls are very easy to read and write from the command line, though, so they're popular for exposing individual tuning parameters. The kernel interfaces for creating sysctls are documented here: https://www.freebsd.org/cgi/man.cgi?query=3Dsysctl&apropos=3D0&sektion=3D9&= manpath=3DFreeBSD+10.1-RELEASE&arch=3Ddefault&format=3Dhtml https://www.freebsd.org/cgi/man.cgi?query=3Dsysctl_add_oid&apropos=3D0&sekt= ion=3D0&manpath=3DFreeBSD+10.1-RELEASE&arch=3Ddefault&format=3Dhtml ioctls are a little more complicated to use, but are more flexible in what kind of data they can accept. The man pages for this aren't as good, but the basic steps are: 1) Create a device node in /dev by calling make_dev() (https://www.freebsd.org/cgi/man.cgi?query=3Dmake_dev&apropos=3D0&sektion= =3D0&manpath=3DFreeBSD+10.1-RELEASE&arch=3Ddefault&format=3Dhtml) 2) In your userland application, call open(2) to get a file descriptor and then ioctl(2) on the file descriptor to pass data to/from the kernel 2) In the cdevsw structure, implement the ioctl method. This method will be called when the userland application calls ioctl(2) 3) The request argument using the macros in . _IOW is for ioctls that send data from userland to the kernel, _IOR is for ioctls that fetch data from the kernel and _IOWR is for ioctls that both send data from userland to the kernel and fetch data back in a single call. Try to use unique values for your ioctls requests. Some of the other possible methods include include mmap, which can be used to create shared memory between the kernel and userland; netgraph, which is networking-focused interface; and sockets, which can be a tricky interface to use correctly in the kernel. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"