Date: Thu, 18 Sep 1997 11:48:55 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: gurney_j@resnet.uoregon.edu Cc: hasty@rah.star-gate.com, mark@grondar.za, multimedia@FreeBSD.ORG Subject: Re: Luigi's sound code not compiling? Message-ID: <199709180948.LAA09596@labinfo.iet.unipi.it> In-Reply-To: <19970918031605.05500@hydrogen.nike.efn.org> from "John-Mark Gurney" at Sep 18, 97 03:15:46 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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/
_____________________________|______________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709180948.LAA09596>