mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Richard B. Johnson" <root@chaos.analogic.com>
To: Ben Greear <greearb@candelatech.com>
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: poll
Date: Thu, 17 Jun 2004 20:19:41 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.53.0406171958570.3414@chaos> (raw)
In-Reply-To: <40D21C8E.4040500@candelatech.com>

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.



  reply	other threads:[~2004-06-18  0:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-17 14:05 poll Richard B. Johnson
2004-06-17 22:34 ` poll Ben Greear
2004-06-18  0:19   ` Richard B. Johnson [this message]
2004-06-18  0:32     ` poll Davide Libenzi
2004-06-18  0:42       ` poll Richard B. Johnson
2004-06-18  2:24     ` poll Ben Greear
2004-06-18 11:22       ` poll Richard B. Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.53.0406171958570.3414@chaos \
    --to=root@chaos.analogic.com \
    --cc=greearb@candelatech.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®