On 07/04/2010 18:39, Albert Lee wrote:
The PreSession script could check the ownership of /dev/audio and only
call "audioctl load-controls" if /dev/audio is already owned by the
user. It is a bit of a drag to follow all the /dev/audio symlinks,
but it would be smarter.
Something that may have
From: Jordan Brown [mailto:jordan.br...@oracle.com]
Sent: Thursday, April 08, 2010 12:24 AM
To: Garrett D'Amore
Cc: psarc-...@sun.com; smb-eng...@oracle.com
Subject: Re: SMB/CIFS Statistics [PSARC/2010/120 FastTrack timeout 04/14/2010]
Garrett D'Amore wrote:
You haven't mentioned anything
On 04/ 8/10 12:07 AM, Jose Borrego wrote:
*From:* Jordan Brown [mailto:jordan.br...@oracle.com]
*Sent:* Thursday, April 08, 2010 12:24 AM
*To:* Garrett D'Amore
*Cc:* psarc-...@sun.com; smb-eng...@oracle.com
*Subject:* Re: SMB/CIFS Statistics [PSARC/2010/120 FastTrack timeout
04/14/2010]
Garre
On 04/ 8/10 02:10 AM, Darren J Moffat wrote:
On 07/04/2010 18:39, Albert Lee wrote:
The PreSession script could check the ownership of /dev/audio and only
call "audioctl load-controls" if /dev/audio is already owned by the
user. It is a bit of a drag to follow all the /dev/audio symlinks,
but i
> as an exercise for yourself, consider how a new
> protocol
> such as RDP (Reliable Datagram Protocl) or ICMP
> would
> be mapped into dtrace using what you're introducing
> as
> the basis of a design for them.
I would think SCTP would be an even more interesting exercise,
since it probably
This case was approved during yesterday's PSARC meeting.
-Seb
___
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
On Thu, Apr 08, 2010 at 06:07:53AM -0700, Garrett D'Amore wrote:
> It would be a good idea to list out the kstats in this case, and
> perhaps declare them Project Private if you don't want to commit to
> supporting them for 3rd party apps.
kstats are scriptable (you can get at them from C, Perl5,
On Wed, Apr 7, 2010 at 5:51 PM, Jordan Brown wrote:
> long list of stats...
I'm running OpenSolaris.recent on my server @home with CIFS, Mac's and
PC's. File write access from the clients is slow; it appears that
something is timing out (not responding) for every initial save-file
request - whic
On Thu, Apr 08, 2010 at 10:36:15AM -0700, John Plocher wrote:
> I presume it is a good thing to have so many stats, and to be able to
> inundate the admin with tons of info, but what is missing for me is
> the conceptual structure to interpret and utilize all this info and to
> actually debug probl
On 08/04/2010 14:14, Garrett D'Amore wrote:
On 04/ 8/10 02:10 AM, Darren J Moffat wrote:
On 07/04/2010 18:39, Albert Lee wrote:
The PreSession script could check the ownership of /dev/audio and only
call "audioctl load-controls" if /dev/audio is already owned by the
user. It is a bit of a drag
Mike:
This resolves my concerns about processes running as root inadvertently
doing bad things or being tricked into doing bad things.
Good, thanks.
It's strange that the Xsession logic respects $AUDIODEV but the
PostSession logic does not. That seems unlikely to produce the correct
results
Garrett D'Amore wrote:
> It would be a good idea to list out the kstats in this case, and perhaps
> declare them Project Private if you don't want to commit to supporting them
> for 3rd party apps.
I'll add that.
- Jose
___
opensolaris-arc mailing li
Darren:
That would be more relevant to the currently running case PSARC 2010/119
"Console User" assignment, logindevperm and virtual console update.
Since that case actually ensures that with multiple X sessions only the
first (ie :0.0 display) has access to the audio device anyway. If the
inte
> -Original Message-
> From: Alan Wright [mailto:alan.wri...@oracle.com]
> Sent: Thursday, April 08, 2010 12:38 PM
> To: Garrett D'Amore
> Cc: psarc-...@sun.com; smb-eng...@oracle.com
> Subject: Re: SMB/CIFS Statistics [PSARC/2010/120 FastTrack timeout
> 04/14/2010]
>
> On 04/ 7/10 10:59
I'd still like a record of the kstats in this case, albeit with Project
Private (or Uncommitted) binding.
Why bother for Project Private interfaces? Because in this case the
kstats are quite visible to end users (as are all kstats) via kstat(1M),
and so I think its useful to record the fact t
On 08/04/2010 18:36, John Plocher wrote:
I presume it is a good thing to have so many stats, and to be able to
inundate the admin with tons of info, but what is missing for me is
the conceptual structure to interpret and utilize all this info and to
actually debug problems. In ARC-speak, what (w
As an outside developer, I would greatly appreciate this. Having had
past projects that tried to do the right thing wrt to consuming kstats
(and reaching brick wall after brick wall), this would greatly help
those of us on the outside navigate things.
On Thu, Apr 8, 2010 at 5:48 PM, Garrett D'Amo
On 04/ 7/10 10:59 PM, Garrett D'Amore wrote:
> On 04/ 7/10 10:47 PM, Jordan Brown wrote:
>> Garrett D'Amore wrote:
>>>
>>> What's missing is an interface table. I think though that based on
>>> the statement that its not to be parsed ("for humans only"), the
>>> output is not-an-interface.
>>
>> Y
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates. All
rights reserved.
1. Introduction
1.1. Project/Component Working Name:
dumpadm -d none
1.2. Name of Document Author/Supplier:
Author: Robert Mil
On 04/08/10 15:48, Garrett D'Amore wrote:
I'd still like a record of the kstats in this case, albeit with Project
Private (or Uncommitted) binding.
Why bother for Project Private interfaces? Because in this case the
kstats are quite visible to end users (as are all kstats) via kstat(1M),
and so
20 matches
Mail list logo
