Support for configuring NWAM via SMF properties doesn't exist. And the
Install team would prefer to not have to understand the details of an
NWAM profile to create one themselves.
Sorry but that comment alone is grounds for derailing the case. There
is an existing "profile" based architecture
On (05/12/10 22:52), Girish Moodalbail wrote:
>
> If the daemon associated with the ip-interface-management service is used to
> configure above addresses on zone boot and address object names were not
> explicitly provided then an address object name will be generated for that
> address by
Darren J Moffat wrote:
Support for configuring NWAM via SMF properties doesn't exist. And the
Install team would prefer to not have to understand the details of an
NWAM profile to create one themselves.
Sorry but that comment alone is grounds for derailing the case. There
is an existing "pro
Darren Kenny wrote:
On 05/13/10 02:33 AM, Mark Haywood wrote:
...
No. I don't consider it an error. It is true that this service will
install a network configuration that will likely be ignored if NWAM is
enabled or enabled at some later point. But it would still serve as the
original conif
Darren J Moffat wrote:
Support for configuring NWAM via SMF properties doesn't exist. And the
Install team would prefer to not have to understand the details of an
NWAM profile to create one themselves.
Sorry but that comment alone is grounds for derailing the case. There
is an existing "pro
With Mark's clarification I'm comfortable with this continuing as a
fast-track for now. I share the concern about NIS and LDAP not being
covered but I don't see that the architecture of this case precludes
equivalent services for those being added (if anything it sets
precedence for how to do
On 05/12/10 16:37, Mark Haywood wrote:
Liane Praza wrote:
On 05/12/10 12:51 PM, Edward Pilatowicz wrote:
some quick questions.
how does this functionality interact with different network management
services, specifically network/physical:nwam and
network/physical:default? is network configurat
Liane Praza wrote:
On 05/12/10 16:37, Mark Haywood wrote:
Liane Praza wrote:
On 05/12/10 12:51 PM, Edward Pilatowicz wrote:
some quick questions.
how does this functionality interact with different network management
services, specifically network/physical:nwam and
network/physical:default? i
On 05/13/10 05:08 AM, sowmini.varad...@oracle.com wrote:
On (05/12/10 22:52), Girish Moodalbail wrote:
If the daemon associated with the ip-interface-management service is used to
configure above addresses on zone boot and address object names were not
explicitly provided then an address
I'm sponsoring this case for John Sonnenschein. A patch release
binding is requested. The proposal.txt is attached. See the case
directory for the rest of the materials.
1. Introduction
1.1. Project/Component Working Name:
GNU coreutils 8.5
1.2. Name of Document Author/Supplier:
> Between 7.4 and 8.5, the following new command was introduced:
>
> /usr/bin/
> nproc
>Location Uncommitted
>Invocation Uncommitted
>Human-readable output
On (05/13/10 08:52), Girish Moodalbail wrote:
>
> ipadm(1M) is going to be new ifconfig(1M) and should be used to manage
> addresses and IP interfaces, going forward. To manage addresses using
> ipadm(1M), they need to have clearly defined names (either user provided or
> daemon generated),
On 05/13/10 09:17 AM, sowmini.varad...@oracle.com wrote:
On (05/13/10 08:52), Girish Moodalbail wrote:
ipadm(1M) is going to be new ifconfig(1M) and should be used to manage
addresses and IP interfaces, going forward. To manage addresses using
ipadm(1M), they need to have clearly defined
On (05/13/10 09:33), Girish Moodalbail wrote:
>
> That is not true.
we digress, but..
>
> # ifconfig ce1 plumb
> # ifconfig ce1 192.168.17.1/24 up
> # ipadm show-addr
> ADDROBJ TYPE STATEADDR
> lo0/v4static ok 127.0.0.1/8
> ce1/_a
On 05/12/10 05:17 PM, Darren Reed wrote:
There seems to be a lot of questions about the details on this case,
as one of the few remaining PSARC members,
There are fifteen PSARC members, twelve of which are currently active
(meaning not on sabbatical), but that's beside the point.
does this
I'm changing the status of this case to "waiting need spec" while the
project team and other interested parties hold offline discussions on
the specifics of this case and its greater context. Thanks to those who
reviewed this case and provided constructive input. Please hold further
comments
This case received a +1 and has timed out. I have marked it approved.
-tim
___
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
On 13/05/2010 15:19, Alan Coopersmith wrote:
Between 7.4 and 8.5, the following new command was introduced:
/usr/bin/
nproc
Location Uncommitted
Invocation Uncommitted
On 2010-05-13, at 7:19 AM, Alan Coopersmith wrote:
>>Between 7.4 and 8.5, the following new command was introduced:
>>
>>/usr/bin/
>>nproc
>> Location Uncommitted
>> Invocation Uncom
nproc uses sysconf(3M) for determining the number of processors on Solaris
which means that zones with CPU pools will see the number in the pool, rather
than the number in the machine.
It may be worthwhile updating the documentation to reflect this, but then again
sysconf(3C) itself is not docu
AFAIK scripts should use getconf tags NPROCESSORS_CONF,
NPROCESSORS_MAX or NPROCESSORS_ONLN (or just NPROCESSORS_ONLN because
it describes the number of currently online cores) to determinate the
number of processors it can use. This works on almost all platforms
(Linux, FreeBSD, OpenBSD) and withi
On 13/05/2010 17:00, John Sonnenschein wrote:
nproc uses sysconf(3M) for determining the number of processors on Solaris
which means that zones with CPU pools will see the number in the pool, rather
than the number in the machine.
That is the answer I was hoping for, I was a little worried it
On 13/05/2010 17:18, ольга крыжановская wrote:
AFAIK scripts should use getconf tags NPROCESSORS_CONF,
NPROCESSORS_MAX or NPROCESSORS_ONLN (or just NPROCESSORS_ONLN because
it describes the number of currently online cores) to determinate the
number of processors it can use. This works on almost
Solaris /usr/bin/**/getconf have a couple of bugs, that's just an old
one you're hitting.
nproc is in the coreutils package because getconf is part of glibc and
not of coreutils and the coreutils authors have already stated their
disapproval for the getconf interface. I'd expect that each time
get
On 13/05/2010 17:34, ольга крыжановская wrote:
Solaris /usr/bin/**/getconf have a couple of bugs, that's just an old
one you're hitting.
nproc is in the coreutils package because getconf is part of glibc and
not of coreutils and the coreutils authors have already stated their
disapproval for the
No, it shouldn't impact the outcome of this case.
I explained where nproc came from. It also has an impact on script
portability because nproc is completely non standard (the lack of
getconf on old platforms and the buggies of getconf implementations
like Solaris getconf is the reason why ksh93 has
On 13/05/2010 17:47, ольга крыжановская wrote:
No, it shouldn't impact the outcome of this case.
I explained where nproc came from. It also has an impact on script
portability because nproc is completely non standard (the lack of
getconf on old platforms and the buggies of getconf implementations
2010/5/13 Darren J Moffat :
> On 13/05/2010 17:47, ольга крыжановская wrote:
>>
>> No, it shouldn't impact the outcome of this case.
>> I explained where nproc came from. It also has an impact on script
>> portability because nproc is completely non standard (the lack of
>> getconf on old platforms
I fail to see how any of this is relevant to this case.
The stability level of nproc is "unstable" and interfaces work on
Solaris, which is the only platform we're concerned with.
If an end user is comfortable using an interface which is disclosed as
unstable, and does the due diligence to se
On 05/13/10 08:19, John Sonnenschein wrote:
On 2010-05-13, at 7:19 AM, Alan Coopersmith wrote:
Between 7.4 and 8.5, the following new command was introduced:
/usr/bin/
nproc
Location Uncommitted
On 05/12/10 04:12 PM, Liane Praza wrote:
This case times out today, has received its +1, and discussion seems to
have closed. I'm marking it closed approved.
liane
Thanks Liane!
I attached the final diff for the manpage, to include in the case materials.
Antonello
--- scf_value_create.3scf.ol
On 05/12/10 11:26 AM, Kacheong Poon wrote:
Attached please find the updated specification of this case.
I've incorporated the comments suggested in the discussion.
Note that this case timed out a few days ago and it has not yet received
a +1. This is a reminder to members that this spec needs
On Wed, May 12, 2010 at 07:23:13PM -0700, sowmini.varad...@oracle.com wrote:
> > - this bit seems odd to me:
> >
> > ---8<---
> > ... Note that IPv4
> > and IPv6 are considered as independent resources, so that
> > specification of an IPv4 address via zonecfg(1m) does not place any
> > constraints
On (05/13/10 13:25), Edward Pilatowicz wrote:
> > Currently, none, though the "only ipv4 specified implies ipv6-addrs
> > are forbidden" approach solves that. In retrospect, that choices
> > seems simpler and cleaner. Is that preferable?
> >
>
> i think so.
Ok, I'll send out an updated spec (t
On Thu, May 13, 2010 at 01:29:20PM -0700, sowmini.varad...@oracle.com wrote:
> > > > - can exclusive stack zones manipulate mac addresses on network
> > > > interfaces?
> > >
> > > yes- they can use 'ifconfig .. ether <..>'.
> > > .. the address property only clamps dow the IP address,
> > > an
+1.
I always felt the interfaces were not really appropriate for generic
drivers to use.
- Garrett
On 05/13/10 03:19 PM, Govinda Tatti wrote:
I'm sponsoring the following fasttrack for Evan Yan. The timer is
set to expire on 05/20/2010.
- Govinda
Template Version: @(#)sac_nextcase
On 13/05/10 01:29 PM, sowmini.varad...@oracle.com wrote:
On (05/13/10 13:25), Edward Pilatowicz wrote:
Currently, none, though the "only ipv4 specified implies ipv6-addrs
are forbidden" approach solves that. In retrospect, that choices
seems simpler and cleaner. Is that preferable?
i think
http://hub.opensolaris.org/bin/view/Community+Group+arc/ARCAgenda/
= OpenSolaris ARC Agenda
= TELECONFERENCE NUMBERS:
(866)682-4770 (Within US)
(408)774-4073 (International)
ACCESS CODE 3950943
SECURITY CODE 6736
Times are US/Pacific Timezone
Meetings are at 10:00 Pacific unless otherwise noted
On Thu, May 13, 2010 at 04:10:05PM -0700, Darren Reed wrote:
> On 13/05/10 01:29 PM, sowmini.varad...@oracle.com wrote:
> >On (05/13/10 13:25), Edward Pilatowicz wrote:
> >>>Currently, none, though the "only ipv4 specified implies ipv6-addrs
> >>>are forbidden" approach solves that. In retrospect
On 05/13/10 07:32 PM, Edward Pilatowicz wrote:
On Thu, May 13, 2010 at 04:10:05PM -0700, Darren Reed wrote:
On 13/05/10 01:29 PM, sowmini.varad...@oracle.com wrote:
Rishi Srivatsavai is looking into the work entailed to have mac-nospoof
enabled for NGZ by default.. just talked to Rishi, and I t
On 13/05/10 04:32 PM, Edward Pilatowicz wrote:
On Thu, May 13, 2010 at 04:10:05PM -0700, Darren Reed wrote:
On 13/05/10 01:29 PM, sowmini.varad...@oracle.com wrote:
On (05/13/10 13:25), Edward Pilatowicz wrote:
Currently, none, though the "only ipv4 specified implies ipv6-addrs
are forbidden"
41 matches
Mail list logo
