Sebastien Roy wrote:
> On Wed, 2009-11-18 at 09:31 -0800, Garrett D'Amore wrote:
>
>> So while I hear what you're saying about the syntax, I'm disagreeing
>> with your suggestions.
>>
>
> I see. I'm fine with the architecture of the case at a high-level, so I
> gave the case a +1 during t
On Wed, 2009-11-18 at 09:31 -0800, Garrett D'Amore wrote:
> So while I hear what you're saying about the syntax, I'm disagreeing
> with your suggestions.
I see. I'm fine with the architecture of the case at a high-level, so I
gave the case a +1 during the meeting today.
-Seb
Some nits on the CLI:
On Mon, 2009-11-16 at 16:54 -0800, Garrett D'Amore wrote:
> audioctl list-devices
>
> audioctl show-device [-v] [-d device ]
>
> audioctl show-control [-v] [-d device] [control ...]
I find it odd that the object specifier for show-device requires an
option, but
Sebastien Roy wrote:
> Some nits on the CLI:
>
> On Mon, 2009-11-16 at 16:54 -0800, Garrett D'Amore wrote:
>
>> audioctl list-devices
>>
>> audioctl show-device [-v] [-d device ]
>>
>> audioctl show-control [-v] [-d device] [control ...]
>>
>
> I find it odd that the object spec
Garrett D'Amore schrieb:
> Cyril Plisko wrote:
>> Since there is new utility being created and there are no issues
>> with backward compatibility, - were any thoughts given to the name
>> "audioadm" vs "audioctl" ?
>>
>> It seems that these days Solaris has many *adm tools, as opposed
>> to only a
On Tue, Nov 17, 2009 at 2:54 AM, Garrett D'Amore
wrote:
> Okay, so I've done the work on this, and I've decided that given "mixerctl"
> was formerly Evolving (and unfortunately has name conflicts with similar,
> yet different, programs from other FOSS), and that it offers zero useful
> functional
J?rg Barfurth wrote:
> Garrett D'Amore schrieb:
>> Cyril Plisko wrote:
>
>>> Since there is new utility being created and there are no issues
>>> with backward compatibility, - were any thoughts given to the name
>>> "audioadm" vs "audioctl" ?
>>>
>>> It seems that these days Solaris has many *adm
Cyril Plisko wrote:
> On Tue, Nov 17, 2009 at 2:54 AM, Garrett D'Amore
> wrote:
>
>> Okay, so I've done the work on this, and I've decided that given "mixerctl"
>> was formerly Evolving (and unfortunately has name conflicts with similar,
>> yet different, programs from other FOSS), and that it
I think audioctl is a better name. However given the nature of mixerctl
I personally would be okay approving incompatible changes to it for a
Minor release binding.
If it is trivial enough to keep mixerctl around with its current CLI and
introduce audioctl, then great that sounds even better.
Okay, so I've done the work on this, and I've decided that given
"mixerctl" was formerly Evolving (and unfortunately has name conflicts
with similar, yet different, programs from other FOSS), and that it
offers zero useful functionality in the Boomer era, that its best to
just EOF.
So, here is
Edward Pilatowicz wrote:
> On Mon, Nov 16, 2009 at 11:02:34AM -0800, Garrett D'Amore wrote:
>
>> Edward Pilatowicz wrote:
>>
>>> so i assume that in the man page below you'll be doing
>>> s/mixerctl/audioctl/. if that's the case then i wonder about the need
>>> for AUDIODEV support. AUDIO
Edward Pilatowicz wrote:
> On Mon, Nov 16, 2009 at 11:02:34AM -0800, Garrett D'Amore wrote:
>
>> Edward Pilatowicz wrote:
>>
>>> so i assume that in the man page below you'll be doing
>>> s/mixerctl/audioctl/. if that's the case then i wonder about the need
>>> for AUDIODEV support. AUDIO
On Mon, Nov 16, 2009 at 11:02:34AM -0800, Garrett D'Amore wrote:
> Edward Pilatowicz wrote:
> >so i assume that in the man page below you'll be doing
> >s/mixerctl/audioctl/. if that's the case then i wonder about the need
> >for AUDIODEV support. AUDIODEV normally points to SADA style audio
> >d
Darren J Moffat wrote:
> I think audioctl is a better name. However given the nature of
> mixerctl I personally would be okay approving incompatible changes to
> it for a Minor release binding.
>
> If it is trivial enough to keep mixerctl around with its current CLI
> and introduce audioctl, th
Edward Pilatowicz wrote:
> so i assume that in the man page below you'll be doing
> s/mixerctl/audioctl/. if that's the case then i wonder about the need
> for AUDIODEV support. AUDIODEV normally points to SADA style audio
> devices, right? but since your introducting a new audioctl tool,
> shou
so i assume that in the man page below you'll be doing
s/mixerctl/audioctl/. if that's the case then i wonder about the need
for AUDIODEV support. AUDIODEV normally points to SADA style audio
devices, right? but since your introducting a new audioctl tool,
shouldn't it be designed to work on boo
Missing new page (sorry I forgot to hit the attach button!):
User Commands mixerctl(1)
NAME
mixerctl -audio mixer control command line application
SYNOPSIS
mixerctl devices
mixerctl info [-v] [-d device ]
mixerctl get [-v] [-d device] [contr
Having just written this up, I just remembered, mixerctl was not an
original invention of mine, but an earlier (and now useless) version of
it existed in Solaris 10 and earlier. I can't make these incompatible
changes as the case stands.
However, there is a simple fix, with the following modif
The following case proposes some incompatible changes to an Uncommitted
interface. However, since the interfaces involved were only introduced in
snv_115, and are not included in any actual official product, I think we can
safely fix this with a fast track.
Template Version: @(#)sac_nextcase 1.68
19 matches
Mail list logo
