[lkml]   [2004]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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).

    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:0.023 / U:7.868 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site