It seems like that would be a reasonable approach, to translate one older interface to the next, if needed, as a compatibility FS. In fact, one such compatibility FS could serve several translations. The best way to deal is to force everyone to update now, or cease functioning, in my opinion. This is where that 'benevolent dictator' approach can really be an advantage, and the disturbance is not usually too bad if you're in a small enough community.
Dave On Wed, Oct 27, 2010 at 1:07 PM, Skip Tavakkolian < skip.tavakkol...@gmail.com> wrote: > would it be hard to provide the backward compatibility via a user fs > -- at least until apps are updated to the new structure? > > On Wed, Oct 27, 2010 at 11:58 AM, Anthony Sorace <a...@9srv.net> wrote: > > I've misplaced my USB audio kit, but I'm reasonably sure I read from > /dev/audio (and a cursory reading of the source suggests that ought to > work). Is there any reason to do otherwise? I don't know what audioin is > intended to buy. Given that it's never been in audio(3), I'm not sure it's > important to support it. > > > > It's unfortunate that volume and audioctl don't support the same > language. Don't add another. It's pretty easy to handle both; see > /sys/src/cmd/usb/audio/audiofs.c. The one for audioctl is reasonably regular > and comprehensive; it'd be nice to standardize our audio interfaces around > that. > > > > I'm more interested in audiostat. I don't see that in the usb > implementation, and I'm not clear on whether it could be provided there. > Anyone know? Should audio programs treat that as optional? > > > > "deprecation" in unix is a mess, where things can stay "deprecated" for > ages. it'd be nice to be able to say "/dev/volume (or /dev/eia0status) was a > mistake; here's a backwards-compatible improvement, and the old stuff goes > away in 6 months." > > > > > >
