From owner-freebsd-drivers@FreeBSD.ORG Thu Nov 3 02:47:28 2005 Return-Path: X-Original-To: freebsd-drivers@freebsd.org Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BA1216A41F for ; Thu, 3 Nov 2005 02:47:28 +0000 (GMT) (envelope-from mayong@mail.com) Received: from webmail-outgoing.us4.outblaze.com (webmail-outgoing.us4.outblaze.com [205.158.62.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C76C43D58 for ; Thu, 3 Nov 2005 02:47:25 +0000 (GMT) (envelope-from mayong@mail.com) Received: from unknown (unknown [192.168.9.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id C3F741800134 for ; Thu, 3 Nov 2005 02:47:24 +0000 (GMT) X-OB-Received: from unknown (205.158.62.81) by wfilter.us4.outblaze.com; 3 Nov 2005 02:47:24 -0000 Received: by ws1-2.us4.outblaze.com (Postfix, from userid 1001) id BB7101F50B1; Thu, 3 Nov 2005 02:47:24 +0000 (GMT) Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 From: "Yong Ma" To: freebsd-drivers@freebsd.org Date: Wed, 02 Nov 2005 21:47:24 -0500 Received: from [159.226.5.225] by ws1-2.us4.outblaze.com with http for mayong@mail.com; Wed, 02 Nov 2005 21:47:24 -0500 X-Originating-Ip: 159.226.5.225 X-Originating-Server: ws1-2.us4.outblaze.com Message-Id: <20051103024724.BB7101F50B1@ws1-2.us4.outblaze.com> Subject: (no subject) X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2005 02:47:28 -0000 Hi all: My driver for the cryptographic accelerator is almost finished,the next= job will be the development of user interfaces.I 've got some problems now= :Is the ioctl() function the only way in which the user implications intera= ct with the driver(mine is a KLD module)?if so,how can I pass some argument= s(such as my private key or the file name that will be encrypted)?Can I cal= l some function(with arguments) defined in the driver in my user implicatio= ns,and how? Thanks! Yong --=20 ___________________________________________________ Play 100s of games for FREE! http://games.mail.com/ From owner-freebsd-drivers@FreeBSD.ORG Thu Nov 3 02:50:39 2005 Return-Path: X-Original-To: freebsd-drivers@freebsd.org Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F46C16A41F for ; Thu, 3 Nov 2005 02:50:39 +0000 (GMT) (envelope-from mayong@mail.com) Received: from webmail-outgoing.us4.outblaze.com (webmail-outgoing2.us4.outblaze.com [205.158.62.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D10C43D48 for ; Thu, 3 Nov 2005 02:50:39 +0000 (GMT) (envelope-from mayong@mail.com) Received: from unknown (unknown [192.168.9.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id D4FDA18001BA for ; Thu, 3 Nov 2005 02:50:38 +0000 (GMT) X-OB-Received: from unknown (205.158.62.51) by wfilter.us4.outblaze.com; 3 Nov 2005 02:50:38 -0000 Received: by ws1-5.us4.outblaze.com (Postfix, from userid 1001) id CAF618401E; Thu, 3 Nov 2005 02:50:38 +0000 (GMT) Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 From: "Yong Ma" To: freebsd-drivers@freebsd.org Date: Wed, 02 Nov 2005 21:50:38 -0500 Received: from [159.226.5.225] by ws1-5.us4.outblaze.com with http for mayong@mail.com; Wed, 02 Nov 2005 21:50:38 -0500 X-Originating-Ip: 159.226.5.225 X-Originating-Server: ws1-5.us4.outblaze.com Message-Id: <20051103025038.CAF618401E@ws1-5.us4.outblaze.com> Subject: Interface of the driver X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2005 02:50:39 -0000 Hi all: My driver for the cryptographic accelerator is almost finished,the next= job will be the development of user interfaces.I 've got some problems now= :Is the ioctl() function the only way in which the user implications intera= ct with the driver(mine is a KLD module)?if so,how can I pass some argument= s(such as my private key or the file name that will be encrypted)?Can I cal= l some function(with arguments) defined in the driver in my user implicatio= ns,and how? Thanks! Yong --=20 ___________________________________________________ Play 100s of games for FREE! http://games.mail.com/ From owner-freebsd-drivers@FreeBSD.ORG Thu Nov 3 04:38:28 2005 Return-Path: X-Original-To: freebsd-drivers@freebsd.org Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B53116A41F for ; Thu, 3 Nov 2005 04:38:28 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0DF543D48 for ; Thu, 3 Nov 2005 04:38:27 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jA34a9Gh000798; Wed, 2 Nov 2005 21:36:14 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 02 Nov 2005 21:36:24 -0700 (MST) Message-Id: <20051102.213624.50069863.imp@bsdimp.com> To: mayong@mail.com From: "M. Warner Losh" In-Reply-To: <20051103025038.CAF618401E@ws1-5.us4.outblaze.com> References: <20051103025038.CAF618401E@ws1-5.us4.outblaze.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 02 Nov 2005 21:36:14 -0700 (MST) Cc: freebsd-drivers@freebsd.org Subject: Re: Interface of the driver X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2005 04:38:28 -0000 In message: <20051103025038.CAF618401E@ws1-5.us4.outblaze.com> "Yong Ma" writes: : My driver for the cryptographic accelerator is almost finished, the : next job will be the development of user interfaces. I've got some : problems now: Is the ioctl() function the only way in which the user : implications interact with the driver(mine is a KLD module)? Yes and no. It is the typical way that most drivers choose to interact with userland. In this model, you have to add a device entry (see make_dev(9)) wher you give it a 'cdevsw' structure. This is the stylized way of doing function potiners for entry points (virtual functions in C++ use a similar mechanism) to the driver. You create a device, the user opens it and then issues requests. In your case ioctl (although I suspect read and write too). : If so, : how can I pass some arguments(such as my private key or the file : name that will be encrypted)? There are a number of macros which help you to pass arguments. The ioctl function itself takes a 'function' and a 'arguement'. Since the 'function' also encodes the size and direction of the ioctl, it can copy the arguments into the kenrel for you and copy them out when you are done. : Can I call some function(with : arguments) defined in the driver in my user implications, and how? Most drivers that define an ioctl interface have a fooio.h header. fooio.h will include and then device their command numbers. For example, mtio.h defines mag tape ioctls: /* mag tape io control commands */ #define MTIOCTOP _IOW('m', 1, struct mtop) /* do a mag tape op */ #define MTIOCGET _IOR('m', 2, struct mtget) /* get tape status */ /* these two do not appear to be used anywhere */ #define MTIOCIEOT _IO('m', 3) /* ignore EOT error */ The first one 'writes' a magtape operation to the kernel. This is contained in a struct mtop. The struct mtop is defined in mtio.h, but I've omitted it here. The driver gets the MTIOCTOP operations, does some casting and then extracts data from the passed in structure. The kernel code looks something like: static int saioctl(struct cdev *dev, u_long cmd, caddr_t arg, int flag, struct thread *td) { int err; ... err = 0; switch (cmd) { ... case MTIOCTOP: { struct mtop *mt = (struct mtop *) arg; err = sa_process_mt(mt); break; } default: err = ENOTTY; break; } ... return (err); } The sa_process_mt routine would be something the driver wrote to interpret the struct mtop from this call. Similarly for other ioctls. _IOW() is for defining ioctls that write data into the kernel only. Most 'set' ioctls are IOW. _IOR are used to extract data from the kernel. Most 'get' ioctls are IOR. _IO ioctls are ioctls that pass no data to the kernel and do some predefined thing (like set the ignore eof flag above). _IOWR are used to pass data both ways, into and out of the kernel. These are used for more complicated 'get' routines or to communicate data back out of the kernel. In userland, the user would just include the fooio.h file and use it like they would for any other ioctl: struct foo_state { ... }; #define FOOIOCGETSTATE _IOR('f', 1, struct foo_state); ... struct foo_state state; int foo; fd = open("/dev/foo0", O_RDWR); if (fd == -1) err(1, "open"); if (ioctl(fd, FOOIOCGETSTATE, &state) == -1) err(1, "IOOIOCFETSTATE"); /* Do something with the state */ close(fd); ... hope this helps.. Warner From owner-freebsd-drivers@FreeBSD.ORG Thu Nov 3 11:05:47 2005 Return-Path: X-Original-To: freebsd-drivers@freebsd.org Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D711716A41F for ; Thu, 3 Nov 2005 11:05:47 +0000 (GMT) (envelope-from mayong@mail.com) Received: from webmail-outgoing.us4.outblaze.com (webmail-outgoing.us4.outblaze.com [205.158.62.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F73F43D45 for ; Thu, 3 Nov 2005 11:05:47 +0000 (GMT) (envelope-from mayong@mail.com) Received: from unknown (unknown [192.168.9.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id C9FCC18001DA for ; Thu, 3 Nov 2005 11:05:46 +0000 (GMT) X-OB-Received: from unknown (205.158.62.81) by wfilter.us4.outblaze.com; 3 Nov 2005 11:05:46 -0000 Received: by ws1-2.us4.outblaze.com (Postfix, from userid 1001) id BC3701F50B2; Thu, 3 Nov 2005 11:05:46 +0000 (GMT) Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 From: "Yong Ma" To: "M. Warner Losh" Date: Thu, 03 Nov 2005 06:05:46 -0500 Received: from [159.226.5.225] by ws1-2.us4.outblaze.com with http for mayong@mail.com; Thu, 03 Nov 2005 06:05:46 -0500 X-Originating-Ip: 159.226.5.225 X-Originating-Server: ws1-2.us4.outblaze.com Message-Id: <20051103110546.BC3701F50B2@ws1-2.us4.outblaze.com> Cc: freebsd-drivers@freebsd.org Subject: Re: Interface of the driver X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2005 11:05:48 -0000 ----- Original Message ----- From: "M. Warner Losh" To: mayong@mail.com Subject: Re: Interface of the driver Date: Wed, 02 Nov 2005 21:36:24 -0700 (MST) >=20 > In message: <20051103025038.CAF618401E@ws1-5.us4.outblaze.com> > "Yong Ma" writes: >=20 > : My driver for the cryptographic accelerator is almost finished, the > : next job will be the development of user interfaces. I've got some > : problems now: Is the ioctl() function the only way in which the user > : implications interact with the driver(mine is a KLD module)? >=20 > Yes and no. It is the typical way that most drivers choose to > interact with userland. In this model, you have to add a device entry > (see make_dev(9)) wher you give it a 'cdevsw' structure. This is the > stylized way of doing function potiners for entry points (virtual > functions in C++ use a similar mechanism) to the driver. You create a > device, the user opens it and then issues requests. In your case > ioctl (although I suspect read and write too). >=20 > : If so, > : how can I pass some arguments(such as my private key or the file > : name that will be encrypted)? >=20 > There are a number of macros which help you to pass arguments. The > ioctl function itself takes a 'function' and a 'arguement'. Since the > 'function' also encodes the size and direction of the ioctl, it can > copy the arguments into the kenrel for you and copy them out when you > are done. >=20 > : Can I call some function(with > : arguments) defined in the driver in my user implications, and how? >=20 > Most drivers that define an ioctl interface have a fooio.h header. > fooio.h will include and then device their command > numbers. For example, mtio.h defines mag tape ioctls: >=20 > /* mag tape io control commands */ > #define MTIOCTOP _IOW('m', 1, struct mtop) /* do a mag tape op */ > #define MTIOCGET _IOR('m', 2, struct mtget) /* get tape status */ > /* these two do not appear to be used anywhere */ > #define MTIOCIEOT _IO('m', 3) /* ignore EOT error */ >=20 > The first one 'writes' a magtape operation to the kernel. This is > contained in a struct mtop. The struct mtop is defined in mtio.h, but > I've omitted it here. The driver gets the MTIOCTOP operations, does > some casting and then extracts data from the passed in structure. The > kernel code looks something like: >=20 > static int > saioctl(struct cdev *dev, u_long cmd, caddr_t arg, int flag, struct=20 > thread *td) > { > int err; > ... > err =3D 0; > switch (cmd) { > ... > case MTIOCTOP: > { > struct mtop *mt =3D (struct mtop *) arg; > err =3D sa_process_mt(mt); > break; > } > default: > err =3D ENOTTY; > break; > } > ... > return (err); > } >=20 >=20 > The sa_process_mt routine would be something the driver wrote to > interpret the struct mtop from this call. Similarly for other ioctls. >=20 > _IOW() is for defining ioctls that write data into the kernel only. > Most 'set' ioctls are IOW. _IOR are used to extract data from the > kernel. Most 'get' ioctls are IOR. _IO ioctls are ioctls that pass > no data to the kernel and do some predefined thing (like set the > ignore eof flag above). _IOWR are used to pass data both ways, into > and out of the kernel. These are used for more complicated 'get' > routines or to communicate data back out of the kernel. >=20 > In userland, the user would just include the fooio.h file and use it > like they would for any other ioctl: >=20 > struct foo_state > { > ... > }; >=20 > #define FOOIOCGETSTATE _IOR('f', 1, struct foo_state); > ... > struct foo_state state; > int foo; >=20 > fd =3D open("/dev/foo0", O_RDWR); > if (fd =3D=3D -1) > err(1, "open"); > if (ioctl(fd, FOOIOCGETSTATE, &state) =3D=3D -1) > err(1, "IOOIOCFETSTATE"); > /* Do something with the state */ > close(fd); > ... >=20 > hope this helps.. >=20 > Warner Thank you very much,it is just what I need! I did as you said but came across some problems: My test application is as follows(ioctltest.c): 1 #include 2 #include 3 #include 4 #include 5 #include 6 7 #define ENCRYPTFILE _IOW("s", 3, struct ioctlinfo) 8 9 struct ioctlinfo{ 10 unsigned long addr; 11 char *buffer; 12 }; 13 14 int main(void){ 15 int fd; 16 struct ioctlinfo info; 17 info.addr=3D0; 18 char *ibuffer=3D"Ioctl test!\n"; 19 printf("Ioctltest:%s\n",ibuffer); 20 info.buffer=3Dibuffer; 21 fd=3Dopen("/dev/sjy22b0",O_RDWR); 22 if(fd=3D=3D-1) 23 err(1,"open"); 24 if(ioctl(fd,ENCRYPTFILE,&info)=3D=3D-1) 25 err(1,"CRYPTFILE!"); 26 close(fd); 27 return (0); 28 } A really simple one:),and the ioctl() in driver adjust as this: ... 313 case ENCRYPTFILE: 314 ioinfo=3D(struct ioctlinfo *)addr; 315 printf("Ioctlinfo :\n addr=3D%ld\nbuffer:%s= \n",ioinfo->addr,ioinfo->buffer); 316 317 break; ... but when I complie the test application(ioctltest.c),it told me: ioctltest.c: In function `main': ioctltest.c:24: error: invalid operands to binary << *** Error code 1 ~~~~~~~~~~~~~~~~~~~~~~~~~~ what's wrong?did I lose any headers or anything else? Thanks Yong --=20 ___________________________________________________ Play 100s of games for FREE! http://games.mail.com/ From owner-freebsd-drivers@FreeBSD.ORG Thu Nov 3 14:25:05 2005 Return-Path: X-Original-To: freebsd-drivers@freebsd.org Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC75C16A423 for ; Thu, 3 Nov 2005 14:25:05 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 051E043D5E for ; Thu, 3 Nov 2005 14:24:52 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1302108 for multiple; Thu, 03 Nov 2005 09:22:52 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA3EOXk9065500; Thu, 3 Nov 2005 09:24:45 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-drivers@freebsd.org Date: Thu, 3 Nov 2005 09:24:28 -0500 User-Agent: KMail/1.8.2 References: <20051103110546.BC3701F50B2@ws1-2.us4.outblaze.com> In-Reply-To: <20051103110546.BC3701F50B2@ws1-2.us4.outblaze.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511030924.29786.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=100 Cc: Subject: Re: Interface of the driver X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2005 14:25:05 -0000 On Thursday 03 November 2005 06:05 am, Yong Ma wrote: > ----- Original Message ----- > From: "M. Warner Losh" > To: mayong@mail.com > Subject: Re: Interface of the driver > Date: Wed, 02 Nov 2005 21:36:24 -0700 (MST) > > > In message: <20051103025038.CAF618401E@ws1-5.us4.outblaze.com> > > > > "Yong Ma" writes: > > : My driver for the cryptographic accelerator is almost finished, the > > : next job will be the development of user interfaces. I've got some > > : problems now: Is the ioctl() function the only way in which the user > > : implications interact with the driver(mine is a KLD module)? > > > > Yes and no. It is the typical way that most drivers choose to > > interact with userland. In this model, you have to add a device entry > > (see make_dev(9)) wher you give it a 'cdevsw' structure. This is the > > stylized way of doing function potiners for entry points (virtual > > functions in C++ use a similar mechanism) to the driver. You create a > > device, the user opens it and then issues requests. In your case > > ioctl (although I suspect read and write too). > > > > : If so, > > : how can I pass some arguments(such as my private key or the file > > : name that will be encrypted)? > > > > There are a number of macros which help you to pass arguments. The > > ioctl function itself takes a 'function' and a 'arguement'. Since the > > 'function' also encodes the size and direction of the ioctl, it can > > copy the arguments into the kenrel for you and copy them out when you > > are done. > > > > : Can I call some function(with > > : arguments) defined in the driver in my user implications, and how? > > > > Most drivers that define an ioctl interface have a fooio.h header. > > fooio.h will include and then device their command > > numbers. For example, mtio.h defines mag tape ioctls: > > > > /* mag tape io control commands */ > > #define MTIOCTOP _IOW('m', 1, struct mtop) /* do a mag tape op */ > > #define MTIOCGET _IOR('m', 2, struct mtget) /* get tape status */ > > /* these two do not appear to be used anywhere */ > > #define MTIOCIEOT _IO('m', 3) /* ignore EOT error */ > > > > The first one 'writes' a magtape operation to the kernel. This is > > contained in a struct mtop. The struct mtop is defined in mtio.h, but > > I've omitted it here. The driver gets the MTIOCTOP operations, does > > some casting and then extracts data from the passed in structure. The > > kernel code looks something like: > > > > static int > > saioctl(struct cdev *dev, u_long cmd, caddr_t arg, int flag, struct > > thread *td) > > { > > int err; > > ... > > err = 0; > > switch (cmd) { > > ... > > case MTIOCTOP: > > { > > struct mtop *mt = (struct mtop *) arg; > > err = sa_process_mt(mt); > > break; > > } > > default: > > err = ENOTTY; > > break; > > } > > ... > > return (err); > > } > > > > > > The sa_process_mt routine would be something the driver wrote to > > interpret the struct mtop from this call. Similarly for other ioctls. > > > > _IOW() is for defining ioctls that write data into the kernel only. > > Most 'set' ioctls are IOW. _IOR are used to extract data from the > > kernel. Most 'get' ioctls are IOR. _IO ioctls are ioctls that pass > > no data to the kernel and do some predefined thing (like set the > > ignore eof flag above). _IOWR are used to pass data both ways, into > > and out of the kernel. These are used for more complicated 'get' > > routines or to communicate data back out of the kernel. > > > > In userland, the user would just include the fooio.h file and use it > > like they would for any other ioctl: > > > > struct foo_state > > { > > ... > > }; > > > > #define FOOIOCGETSTATE _IOR('f', 1, struct foo_state); > > ... > > struct foo_state state; > > int foo; > > > > fd = open("/dev/foo0", O_RDWR); > > if (fd == -1) > > err(1, "open"); > > if (ioctl(fd, FOOIOCGETSTATE, &state) == -1) > > err(1, "IOOIOCFETSTATE"); > > /* Do something with the state */ > > close(fd); > > ... > > > > hope this helps.. > > > > Warner > > Thank you very much,it is just what I need! > I did as you said but came across some problems: > My test application is as follows(ioctltest.c): > > 1 #include > 2 #include > 3 #include > 4 #include > 5 #include > 6 > 7 #define ENCRYPTFILE _IOW("s", 3, struct ioctlinfo) > 8 > 9 struct ioctlinfo{ > 10 unsigned long addr; > 11 char *buffer; > 12 }; > 13 > 14 int main(void){ > 15 int fd; > 16 struct ioctlinfo info; > 17 info.addr=0; > 18 char *ibuffer="Ioctl test!\n"; > 19 printf("Ioctltest:%s\n",ibuffer); > 20 info.buffer=ibuffer; > 21 fd=open("/dev/sjy22b0",O_RDWR); > 22 if(fd==-1) > 23 err(1,"open"); > 24 if(ioctl(fd,ENCRYPTFILE,&info)==-1) > 25 err(1,"CRYPTFILE!"); > 26 close(fd); > 27 return (0); > 28 } > > A really simple one:),and the ioctl() in driver adjust as this: > ... > 313 case ENCRYPTFILE: > 314 ioinfo=(struct ioctlinfo *)addr; > 315 printf("Ioctlinfo :\n > addr=%ld\nbuffer:%s\n",ioinfo->addr,ioinfo->buffer); 316 > 317 break; > ... > but when I complie the test application(ioctltest.c),it told me: > > > ioctltest.c: In function `main': > ioctltest.c:24: error: invalid operands to binary << > *** Error code 1 ~~~~~~~~~~~~~~~~~~~~~~~~~~ > > what's wrong?did I lose any headers or anything else? Use 's' rather than "s" in _IOW. Also, ioctl() is just going to copy in the info structure, it's not going to follow pointers inside that structure for you. You would have to copy that in from userland explicitly. Something like: char buffer[MAXPATHLEN]; ... case ENCRYPTFILE: ioinfo = (struct ioctlinfo *)addr; error = copyinstr(info->buffer, &buffer, sizeof(buffer), NULL); if (error) return (error); printf("Ioctlinfo:\naddr=%ld\nbuffer:%s\n", info->addr, buffer); break; Alternatively, you could change the info struct to contain the buffer rather than the pointer like so: struct ioctlinfo { unsigned long addr; char buffer[MAXPATHLEN]; }; And in userland: info.addr = 0; strcpy(ibuffer, info.buffer); ioctl(fd, ENCRYPTFILE, &info); And in kernel you can do: case ENCRYPTFILE: ioinfo = (struct ioctlinfo *)addr; printf("IoctlInfo:\naddr=%ld\nbuffer:%s\n", info->addr, info->buffer); break; -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org