From owner-freebsd-multimedia  Thu Sep 18 04:15:39 1997
Return-Path: <owner-freebsd-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA29051
          for multimedia-outgoing; Thu, 18 Sep 1997 04:15:39 -0700 (PDT)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA29039
          for <multimedia@FreeBSD.ORG>; Thu, 18 Sep 1997 04:15:28 -0700 (PDT)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA09596; Thu, 18 Sep 1997 11:48:56 +0200
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199709180948.LAA09596@labinfo.iet.unipi.it>
Subject: Re: Luigi's sound code not compiling?
To: gurney_j@resnet.uoregon.edu
Date: Thu, 18 Sep 1997 11:48:55 +0200 (MET DST)
Cc: hasty@rah.star-gate.com, mark@grondar.za, multimedia@FreeBSD.ORG
In-Reply-To: <19970918031605.05500@hydrogen.nike.efn.org> from "John-Mark Gurney" at Sep 18, 97 03:15:46 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-multimedia@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > I share the feeling... at the very least I wonder why the change has
> > not been made in a way to insure backward compatibility, e.g. without
> > changing procedure names and types, augmenting the values passed in
> > former "rw" (now "events") parameters, and making checks on the return
> > value more tolerant for old interfaces.
> 
> because the problem is that how would you know to use the old interface,
> and there is not an easy way to convert the new interface to the old
> interface.. what do you do with new options? just not pass them.. then
> you end up with kernel bloat because no one changed the last few drivers
> over to the new code..

the old interface was passed either FREAD, FWRITE or 0 in response
to a select() call, and returned 1 if successful, 0 if not.  If I
am not mistake, in the kernel is

#define FREAD           0x0001
#define FWRITE          0x0002

I do hope the semantics of select(2) have not changed, so select()
could use the old interface.

While I have not seen any docs (sorry, I am fighting with a lossy
connection...), I assume the new poll(2) allows you to specify an
extended set of desired events through a combination of the following
flags:

#define POLLIN          0x0001          /* any readable data available */
#define POLLPRI         0x0002          /* OOB/Urgent readable data */
#define POLLOUT         0x0004          /* file descriptor is writeable */
#define POLLRDNORM      0x0040          /* non-OOB/URG data available */
#define POLLWRNORM      POLLOUT         /* no write type differentiation */
#define POLLRDBAND      0x0080          /* OOB/Urgent readable data */
#define POLLWRBAND      0x0100          /* OOB/Urgent data can be written */

(on passing, I notice a certain asymmetry between read and write,
and we have POLLPRI and POLLRDBAND which from the description appear
to be the same ?)

If POLL* were not overlapped to FREAD/FWRITE, a poll() call for
simple events (e.g. just POLLIN, or POLLOUT let's say) could be
mapped into the old FREAD/FWRITE. More complex requests involving
combinations of the above could just be passed to the driver routine;
at this point an old one would fail to recognize the request and
return 0 (or 1 if the driver is broken...). To make things fully
compatible the poll interface could be specified so that a return
of 0 or 1 is only considered valid in response to a old-style
request, so that the kernel could detect that the driver does not
implement the requested functionality and pass up POLLNVAL

In pseudo C:

... redefine POLLIN and POLLOUT not to use 1 or 2 ...
... make the new-style device-specific poll routine always return a value
... which is different from 0 or 1

poll(... events ...)
{
    int ev = events;
    int ret ;

    if (ev == POLLIN) ev = FREAD;
    else if (ev == POLLOUT) ev = FWRITE;
    ret = device->poll( ... ev ... );
    if (ev == FREAD)
	if (ret != 0 ) ret = POLLIN ;
    else if (ev == FWRITE)
	if (ret != 0 ) ret = POLLOUT ;
    else {
	if (ret == 0 || ret == 1)
	    ret = POLLNVAL ;
    }
}

	Luigi
-----------------------------+--------------------------------------
Luigi Rizzo                  |  Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it    |  Universita' di Pisa
tel: +39-50-568533           |  via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522           |  http://www.iet.unipi.it/~luigi/
_____________________________|______________________________________