[EMAIL PROTECTED] wrote:
>> Right now, I have a driver (the audio subsystem I'm working on) which
>> will ultimately want to be integrated into Nevada. But it wants to
>> access some fields in the uarea of the process that opened the driver
>> initially -- specifically the command and arguments.
>>
>> 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));
>> }
>>
>>
>>
>
> I can only say: Gross!
>
> I'm surprised that you need to do this in a driver, apparently it also
> means that you have a set of applications you need to change differently.
>
> Certainly, anything in Solaris should be fixed when the audio framework
> is changed, including GNOME and other programs.
>
> What programs are we talking about? And what exactly do you differently
> for those applications?
>
The programs that need to trigger different behavior based on u_comm are
the gnome mixer and volume control applications. Its likely that this
will be needed for other volume applications/applets (e.g. whatever KDE
uses) as well.
> And if I happen to use one of those names for one of my applications,
> will it work differently if I rename it?
>
The difference will be the semantics applied to AUDIO_GETINFO and
AUDIO_SETINFO when used against /dev/audioctl. Specifically, values set
or returned will be the values for the underlying hardware rather than
for any logical channel associated with /dev/audio.
A number of buggy audio applications (the list of them is too great to
list here) use /dev/audio and /dev/audioctl *interchangeably*, expecting
the values and settings to be synchronized. These applications are not
mixer aware, and have usage that was appropriate when there was only one
unshared audio device (which could only ever be used exclusively).
Newer applications can use newer ioctls that specifically target either
logical channel or hardware, and are unambiguous.
The existing Sun audio framework is somewhat buggy here as well. The
problem is indeterminism in the current framework about whether settings
are applied to a logical channel or to the hardware.
Your renamed application (using one of the new names) may work
properly. Then again, it might not. It depends on whether it uses
/dev/audioctl, and whether it makes bogus assumptions about linkage
between /dev/audioctl and /dev/audio. (Specifically some values, such
as the sample and eof counters, will *not* be synchronized between
/dev/audio and /dev/audioctl for these particular applications.)
-- Garrett
> Casper
>
>
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
