From owner-freebsd-hackers Sat Feb 1 17:55:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA23773 for hackers-outgoing; Sat, 1 Feb 1997 17:55:12 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA23766 for ; Sat, 1 Feb 1997 17:55:08 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id RAA18732; Sat, 1 Feb 1997 17:20:47 -0800 (PST) Message-ID: <32F3EB83.41C67EA6@whistle.com> Date: Sat, 01 Feb 1997 17:18:59 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: "Brian J. McGovern" CC: hackers@freebsd.org Subject: Re: Device driver help needed... References: <199702012336.SAA12533@spoon.beta.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian J. McGovern wrote: > > Ok. I'm sure that now I've terribly bastardized the uio structure, but at > least the damn thing compiles :) Let see if I can get some comment > on my interpretation of the uio stucture: > > struct uio > { > struct iovec *uio_iov; /* Pointer to IO Vector (possible array?) */ pointer to ARRAY OF IOVECS (POSSIBLY ONLY 1) (I know that's what you said but....) > int uio_iovcnt; /* Number of IO vectors (?) */ (size of array above) > off_t uio_offset; /* Offset in to device */ > int uio_resid; /* Length of read request (?) */ number of bytes STILL TO BE TRANSFERED > enum uio_seg uio_segflg; /* I assume a segment of some kind, but I > can only find reference to UIO_SYSSPACE */ the addresses in the iovec are to be interpretted as being in: KV space, User space, etc.etc. > enum uio_rw uio_rw; /* UIO_READ or UIO_WRITE (type of operation(?)) */ yes.. TO or FROM the addresses inn the iovec array > struct proc *uio_procp; /* No idea, but I've seen it set to curproc */ pointer of the proc structure associated with the operation needed if using UIO_USERSPACE. > }; > > Ok, guys. Beat me up, and let me know whats incorrect. > > With that in mind, I've bent my device driver to look like this: > > ------ foo.c --------------------------------------- > #define KERNEL > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #ifdef DEVFS > #include > #endif > #include > #include > #include > > static char message[] = "The quick brown fox jumps over a lazy dog\n"; > > #define CDEV_MAJOR 20 are you sure 20 is unused? I guess it's for local use.. that's fine. > > static d_read_t fooread; > > static struct cdevsw foo_cdevsw = > { > nxopen, nxclose, fooread, nxwrite, > nxioctl, nxstop, nxreset, nxdevtotty, > nxselect, nxmmap, NULL, "foo", NULL, -1 > }; > you are going to have trouble openning the device if it returns ENXIO.. (nxopen?) > fooinit() > { > } > > static int fooread(dev,myuio, flag) > dev_t dev; > struct uio *myuio; > int flag; > { > unsigned char *buffer_pointer; > int toread; > if ((myuio->uio_iovcnt != 1) || (MINOR(dev) != 0)) what if it's 2? > return ENODEV; and anyway, wouldn't EINVAL be a better response to no user memory buffer.. > while(myuio->uio_resid) exactly.. keep doing it till we have the required data. > { > buffer_pointer = (message + (myuio->uio_offset % sizeof(message))); what's message? is this a ring buffer? > toread = ((long unsigned int)(message + sizeof(message)) - (long unsigned int)buffer_pointer); I don't follow this very well. > uiomove(buffer_pointer, toread, myuio); yep.. (I haven't chaecked the arguments but that's the basic idea how about checking the return value of uiomove eh? it returns an errno value you can pass straight to the user. (return it, the syscall code will put it into errno.) > myuio->uio_offset + toread; you mean += surely.. > myuio->uio_resid = myuio->uio_resid - toread; using -= would be more readable.. > } > } > #define CDEV_MAJOR 20 > > ------------------------------------------------- > > Now, I'm sure there are bugs in there. Hell, I didn't know what I was doing > half the time :) But, now its time to start debugging, which means I need > to get it in to the kernel. Someone mentioned using SYSINIT to get it working > as a pseudo-device driver. The file above is located in > /usr/src/sys/i386/addons/foo.c. Anyone care to give me a set of steps (and > code changes) to get it in the kernel? Thanks. > -Brian ok cd /sys/i386/conf cp GENERIC MYKERN cat > /sys/i386/conf/files.MYKERN <>MYKERN <