lkml.org 
[lkml]   [2004]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: poll
On Thu, 17 Jun 2004, Ben Greear wrote:

> Richard B. Johnson wrote:
> > Hello,
> > Is it okay to use the 'extra' bits in the poll return value for
> > something? In other words, is the kernel going to allow a user-space
> > program to define some poll-bits that it waits for, these bits
> > having been used in the driver?
>
> Can't you just do a read and determine from the results of the read
> what you actually got? If not, add framing to your message so that
> you *CAN* determine one message type from another...
>
> Ben
>

The mailbox read(s) is/are 32-bit int(s). There is no way to identify
it as being "new" or something that was written two weeks ago.
That's why we use poll. Poll says 'I got something new for you'.

If I can't use 'spare' bits in poll to identify what I want to
go get I would need to make a separate system-call ioctl() to
find out what it is. This is wasteful of time that is very scarce.

If I returned that information in some kind of structure (descriptor),
then the process that gets the information, including the mailbox
content, will probably not be the process that needs that mailbox
content so another task would need to get something that has already
been read and the resulting poll bits already cleared. The driver
has no way of knowing which of the open file-descriptors needs
such-and-such information. Only the user-mode code knows that.

Currently, everybody who is sleeping in poll() gets awakened when
a new mail-box message is available. They all check to see if the
bit is one they are waiting for. If so, they execute an ioctl() that
gets the specific mailbox content and resets the poll-flag bit.

This all works fine-and-dandy with kernel 2.4.26. However, Linux
has a history of removing availability of undefined things. If
it is not intended that the extra bits be used, my bet is that
somebody will immediately patch the kernel to AND the poll-flag
with 0x3ff, probably for spite, and future kernels won't
have the existing capability. So I need to know soon if this
is going to be done. If so, I probably need to find some other
way (maybe some other OS --no not that one, that's not an OS...,
but the Bee one may be more suitable for embedded stuff considering
that Linux has exploded).

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [from the cache]
©2003-2011 Jasper Spaans