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?
If not, then I guess I have to use POLLPRI and then the listener
will have to call an ioctl() function to find out what event it
really was. This seems very dumb.
I have three events I need to poll for, normal data available,
a mailbox message available, and another mailbox message available.
If, for instance, all the high-bits in the poll-flag are available,
then I could use two for the mail-box messages. However, if the kernel
uses them for something else, or ignores them, then I'm screwed and
have to make extra ioctl() calls to satisfy some abitrary rules.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.
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
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.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.
On Thu, 17 Jun 2004, Richard B. Johnson wrote:
> This all works fine-and-dandy with kernel 2.4.26. However, Linux
> has a history of removing availability of undefined things.
It'd work just fine in 2.6. The poll infrastructure is just a proxy to the
event core, and shouldn't mask anything. Your driver's f_op->poll will
return a mask, and this will be and'ed with the mask that you pass to poll(2).
Non-zero results will be reported to you. Just do not use bits 30 and 31
if you want it to work with epoll.
- Davide
On Thu, 17 Jun 2004, Davide Libenzi wrote:
> On Thu, 17 Jun 2004, Richard B. Johnson wrote:
>
> > This all works fine-and-dandy with kernel 2.4.26. However, Linux
> > has a history of removing availability of undefined things.
>
> It'd work just fine in 2.6. The poll infrastructure is just a proxy to the
> event core, and shouldn't mask anything. Your driver's f_op->poll will
> return a mask, and this will be and'ed with the mask that you pass to poll(2).
> Non-zero results will be reported to you. Just do not use bits 30 and 31
> if you want it to work with epoll.
>
> - Davide
>
Thanks. That's what I wanted to hear.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.
Richard B. Johnson wrote:
> 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'.
Then use 3 different file descriptors to poll/read. That seems more
efficient anyway as it doesn't wake the folks who don't care.
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Thu, 17 Jun 2004, Ben Greear wrote:
> Richard B. Johnson wrote:
> > 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'.
>
> Then use 3 different file descriptors to poll/read. That seems more
> efficient anyway as it doesn't wake the folks who don't care.
>
> Ben
Huh?? The driver has no clue what open file-descriptor needs
whatever special handling. When a polled-for event occurs, a
bit is put into what will be the poll return value in the driver
and any process sleeping in poll ** that is waiting for that bit **
gets awakened. That's why I need to use some of the "spare" bits.
Only the task that's waiting for its specific bit gets awakened
in user-mode.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.