On Tue, Oct 14, 2008 at 11:28:51AM -0700, Garrett D'Amore wrote:
> My code currently does this horribly non-DDI compliant method:
>
> if (ttoproc(curthread)) {
> bcopy(PTOU(ttoproc(curthread))->u_comm,
> c->c_command, sizeof (c->c_command));
> bcopy(PTOU(ttoproc(curthread))->u_psargs,
> c->c_psargs, sizeof (c->c_psargs));
> }
Presuming there's not a better way to solve your problems, then IMHO
this is the *right* thing to do. A driver-specific hack shouldn't be
sanctified in the DDI. This needs to go along with a large comment
explaining exactly why this is necessary. People seeing the code will
immediately stop and think "what the hell is going here..." which is the
correct response!
> 1) u_comm is required so that I can trigger different behavior for
> different applications. Basically I have to deal with buggy
> applications, that are preexisting. In order to tell whether an
> application is a "mixer panel" or a "regular audio client" I have to
> rely on the application to self-identify with certain ioctls. But
> legacy applications don't do this, and (ab)use other legacy ioctls with
> old-style audio semantics. By looking at u_comm, I can identify
> applications that should have self identified (the gnome mixer panel and
> volume controls for one!) and give them the correct semantics. (In this
> case, their use of AUDIO_SETINFO should go to the real hardware to
> affect system-wide settings instead of only applying to a virtual
> channel for the application itself.)
GNOME isn't interesting since we can fix that. Presumably there's some
significant unbundled software that is broken like this. For case 1),
isn't LD_PRELOAD of a fixup library better?
> 2) u_psargs is required to implement properly the OSS API that we
> "inherit" from Linux. Basically, applications (such as mixer panel
> applications) expect to be able to know what command is using a virtual
> channel.
What exactly do they do with this information? Are unbundled mixers
really that interesting?
regards
john
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
