John Levon wrote:
> 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!
>
Sure, a comment is trivial. But I *hate* doing this, because it means
that the binary becomes locked to the kernel release. I'd prefer an
interface (even if it is not officially part of the DDI) that was
resilient against changes in the structures involved. (For example, the
above code would tie the audio subsystem to these core kernel
structures, which would mean that any patch that changed their offsets
would also need to include replacement binaries for the audio
subsystem! Yech.)
>
>> 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?
>
I'm not sure how LD_PRELOAD really solves the problem, except that it
requires users (and desktop environments, potentially!) to alter their
environment. This is not a good solution, IMO. The best solution is
one where everything Just Works.
And yes, if Gnome (and any other desktop sound systems) can be "fixed",
it certainly makes my life easier, and at that time I'd be happy to yank
the code.
One of my significant questions, though, is, are we certain that no
other useful cases for this information exist. Certainly there places
throughout the kernel that uses this information, although they are all
for fairly "bundled" components (such as the filesystem code, dtrace and
kstat helpers, etc.)
>
>> 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?
>
The idea is a panel app that shows all the commands and gives individual
control over the levels associated with each running command.
Windows Vista has something like this. Our own sdtaudiocontrol has the
same thing, but only shows the process id, which isn't terribly
informative to ordinary humans.
But in any case, the problem I have here is that I have to retain
fidelity to the OSS APIs. (It would be a *lot* easier if I could just
invent my own replacement APIs. A lot of "insane" things could much
more trivially be fixed.)
-- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
