[vox-tech] Driver Question

[Mark K. Kim]

I think I understood it correctly but I wasn't sure exactly how to do it
so I was just giving you some pointers.  Anyway, I'm sorta interested in
this too so I poked around a bit some more.  Looks like the easiest
technique is to:

   (1) Trap SIGIO signal using signal() system call.
   (2) fcntl(fd, F_SETFL, O_ASYNC);
   (3) fcntl(fd, F_SETOWN, getpid());  (might not be necessary)
   (4) wait for SIGIO signal, handle it in your signal handler.

I haven't tried it.  If it doesn't work, refer to the "fcntl" man page and
look for any information on asynchronous I/O (grep for "async").  If that
doesn't work either, try reading section 12.6 in "Advanced Programming in
the UNIX Environment" by W. Richard Stevens.

BTW, the above technique seems to be a Linux-ism so I'm not sure how it
will fare on other *NIX.  Stevens explains there are two different
techniques (one for SVR4 and one for 4.3+BSD), and Linux's technique seem
like the neither one.  Good luck!

-Mark


On Sun, 14 Sep 2003, John Wojnaroski wrote:

> I think I may have mis-stated the problem, my apologies. I'll try again...
>
> In this case the app is a real-time simulation and the hardware provides a
> user interface for entering data and a set of switch states. Most of the
> time the driver will interact with the hardware updating displays, states,
> etc. These interrupts never get to the app level, however when the operator
> depresses one of any number of push buttons specific data is read into the
> driver's kernel space and this data needs to get to the app. So rather than
> have the app checking or polling to see if data is available it seems it
> would be more efficient to issue some signal to an app function to read the
> data from kernel to user space. I've been browsing thru the keyboard drivers
> and others to try an find an example, no luck so far. In a nutsell, then
>
> operator pushes a button, hardware generates an interrupt which launches
> driver, driver reads data clears interrupt,
> next, how to notify app that data is available and should be read
>
> Thinking some sort of app function that sleeps and is alerted by some ioctl
> signal or whatever. How does the keyboard work? Would not this be a similar
> implementation?
>
> Regards
> John W
>
>
> ----- Original Message -----
> From: "Mark K. Kim" <markslist@cbreak.org>
> To: <vox-tech@lists.lugod.org>
> Sent: Sunday, September 14, 2003 9:45 PM
> Subject: Re: [vox-tech] Driver Question
>
>
> > The app is supposed to block ("freeze") if the data hasn't been read by
> > the driver.  It stays blocked ("frozen") until the data is available.
> >
> > The app can choose to not block in such situation, by using the "select"
> > or "poll" system call.  If the file descriptor is set to non-blocking
> > mode, and if no data is available, then the read() system call returns -1
> > and sets "errno" to "EAGAIN".  You probably have to implement these
> > features into the driver.
> >
> > Have fun~!
> >
> > -Mark
> >
> >
> > On Sun, 14 Sep 2003, John Wojnaroski wrote:
> >
> > > Hi,
> > >
> > > Building a driver for a hardware board and things are looking good...
> Using
> > > the O'Reilly book by Rubini and Corbet as a guide, but have a bit of a
> > > question??
> > >
> > > The driver is interrupt driven when the board posts data to the port and
> > > that works fine. Data is retreived and stored in kernel space and the
> app
> > > can use "result = read(fd, mesg, sizeof data)" to access the file (a
> char
> > > device). But I can't seem to figure out how to notify the app that the
> > > driver has read the data.
> > >
> > > Rather than polling would just like to read when data has been updated (
> > > kind of like a keyboard using a callback function)
> > >
> > > Any thoughts, hints, references would be appreciated.
> > >
> > > Thanks
> > > John W
> > >
> > > _______________________________________________
> > > vox-tech mailing list
> > > vox-tech@lists.lugod.org
> > > http://lists.lugod.org/mailman/listinfo/vox-tech
> > >
> >
> > --
> > Mark K. Kim
> > http://www.cbreak.org/
> > PGP key available on the website
> > PGP key fingerprint: 7324 BACA 53AD E504 A76E  5167 6822 94F0 F298 5DCE
> >
> > _______________________________________________
> > vox-tech mailing list
> > vox-tech@lists.lugod.org
> > http://lists.lugod.org/mailman/listinfo/vox-tech
>
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech
>

-- 
Mark K. Kim
http://www.cbreak.org/
PGP key available on the website
PGP key fingerprint: 7324 BACA 53AD E504 A76E  5167 6822 94F0 F298 5DCE