Date: Thu, 16 Oct 2003 11:01:01 +0100 From: Bruce M Simpson <bms@spc.org> To: lauri.jarvenpaa@students.turkuamk.fi Cc: freebsd-hackers@freebsd.org Subject: Re: to write a device driver or not to write (i/o, opl3, stupidity) Message-ID: <20031016100101.GG3470@saboteur.dek.spc.org> In-Reply-To: <20031015211329.GE1810@cnd.mcgill.ca> References: <20031016000052.648ca035.lauri.jarvenpaa@students.turkuamk.fi> <20031015211329.GE1810@cnd.mcgill.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I mean, what services do drivers offer? What services they _need_ to offer? Do they just create appropriate device nodes and let the applications to worry about using them or do they do some data manipulation or do they offer routines and interfaces for applications or what? What should this particular driver do as I just want to read/write data. > > I think for your application running in userland is fine, if kernel programming is likely to be a steep learning curve. You can use nanosleep() to get the timing you need. On Wed, Oct 15, 2003 at 05:13:29PM -0400, Mathew Kanner wrote: > I'm not positive about this but I think that you can do it > from usermode by opening /dev/io (as root) and the use inb, outb > macros defined in cpufunc.h. You can also use i386_get_ioperm() and i386_set_ioperm(). These change the I/O port permission bitmap in the process's Task State Segment (TSS) accordingly, so that you can issue IN/OUT instructions without segfaulting in a similar way to opening /dev/io. The only trouble with /dev/io is that it's an all-or-nothing approach (processes literally can write anywhere in I/O space); better to ask for what you need than ask for everything, IMHO. BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031016100101.GG3470>