John Levon wrote:
> On Tue, Oct 14, 2008 at 09:04:34PM -0700, Garrett D'Amore wrote:
>
>
>>> 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.
>>
>
> Yes, but at what cost?
>
>
>> 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.
>>
>
> Then that seems the way to go. Have you filed bugs against the relevant
> code? Is it easy to find examples on google codesearch?
>
Not yet. I asked on the #gstreamer and didn't even get any response.
>
>> 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.)
>>
>
> You're using it for two things:
>
> 1) hacks for particular applications
>
> We're not Microsoft and we're not obliged to bend over backwards for
> applications stepping out of the APIs guaranted by the binary compat
> guarantee. There comes a point where doing this is an awful idea for
> long term maintainability. A perfect example would be changing the libc
> allocator if the binary is SimCity (yes, they really did do this).
>
The problem isn't completely the the applications. It's a buggy (very
badly) API as well, and we some how have to retain fidelity to it. The
existing Sun audio API is totally brain damaged here. Having the
behavior of AUDIO_GETINFO and AUDIO_SETINFO change depending on what
other files are open was a rotten design decision done when the original
Sun mixer was designed. It has led to several subtle bugs that result
in strange inconsistencies when you try to do volume control.
> Brands are a much much better solution to this general problem.
>
> 2) providing ownership information
>
> Arbitrary strings are a terrible way of indicating this. Some form of
> contract would be the clean, correct way of doing something similar in
> Solaris, along with contract decoration.
>
Applications have a way to override this information in OSS. The
process command line is just a first pass at the information done on
behalf of applications that don't know how to do this. (And all legacy
Sun audio applications, and about 95% of legacy OSS applications fall
into this category.)
>
>> 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's a shame there isn't liboss or something then. To say the least, not
> a great design, but I think you know that already :)
>
> Again, which mixer is both important to Solaris and unbundled?
>
I don't know. I don't have the full set of audio applications. I do
know that we are contractually obligated to retain fidelity to the
APIs. Changes to the API would solve a lot of my problems.
-- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
