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>