Erik Nordmark wrote:
Perhaps I didn't see it, but which (if either)
MTU corresponds
to what may be publically seen? Or does it
matter (if IP
fragmenting hides the distinction)?
IP fragmentation hides the distinction.
It is the unicast MTU that is reported using the
[...]
Disclaimer: I'm no network guru, and this is the
first time I've so much
as looked at RFCs 4391 and 4755. I have no idea what
other
implementations supporting IPoIB-CM do (it might be
worth finding
out...).
Ok, I looked (minimally), and I _think_ Linux is generally
allowing the
[...]
It seems a shame to me that the architecture for this
new feature stops
at the IP/driver connection and doesn't include the
API level.
--
James Carlson 42.703N 71.076W
carls...@workingcode.com
Particularly since the information is already available - the UD MTU
has
[...]
network overhead. The
only question being if there's some precedent in
another implementation
for what the API should look like. I'm having
trouble thinking up a
likely google/bing query for that...
In attempting to find a precedent (without luck so far, and
I'll probably run out of
Perhaps I didn't see it, but which (if either) MTU corresponds
to what may be publically seen? Or does it matter (if IP
fragmenting hides the distinction)?
--
This message posted from opensolaris.org
___
opensolaris-arc mailing list
Richard L. Hamilton wrote:
Beware that if you have getprogname(), you may find
people wanting
the entire FreeBSD err(3) family,
Already there:
changeset: 4891:f4f971e9574d
user:vk199839
date:Sat Aug 18 10:07:23 2007 -0700
description:
PSARC/2006/662 Make err/warn
re getprogname(): since I don't see man pages in the public case
directory,
* is there also a setprogname() as in at least some FreeBSD? If so,
is it implicit in the run-time startup, or does one need to call it explicitly?
* since argv[0] can be anything, is this equivalent to getexecname()
What SUSv4 functions are still missing after this case?
Have requests been filed for them? As an example, I didn't
see wcsnlen().
--
This message posted from opensolaris.org
___
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
On 7/26/10 12:10 PM, Antonello Cruz wrote:
Well, your second email came just when I had
finished my reply. Since it
is not immediately clear why I am restricting
access to the files in
/etc/logadm.d I'll send my original reply here
anyway.
logadm can run arbitrary scripts defined
On 07/26/10 09:32 AM, Peter Memishian wrote:
Seeing yet another involvement of /etc/
symlinks brought by Darren leads
me to question the architectural value of the
proposed changes.
I like cleanlyness. I also like
compatibility. This seems architecturally
to me like
[...]
I'm not saying don't do it; I'm saying I'd want (a) a
_very_ careful reading
of standards to see if extensions are allowed, given
such behavior; and
[...]
Just looked it up at
http://www.opengroup.org/onlinepubs/9699919799/utilities/expr.html
which says:
The use of string arguments
Using the older behavior of expr vs the new (as seen in /usr/gnu/bin/expr)
(both of these SPARC snv_97, but that's irrelevant to my point):
$ x=index
$ /usr/bin/expr $x = i=
0
$ /usr/gnu/bin/expr $x = i=
1
In other words, because commands called from the shell have no way to
know what
On 6/18/10 9:52 PM, Cynthia McGuire wrote:
Template Version: @(#)sac_nextcase 1.70 03/30/10
SMI
This information is Copyright (c) 2010, Oracle
and/or its affiliates. All rights reserved.
Seem to be missing some content here ... did you
perhaps forget to
forward something?
For
[...]
There may or may not be customer scripts reading the
files in this case,
but I don't know of anything specific and any modern
version of sendmail
should not, at least.
Hugh.
FYI, a number of Linux distros (and Mac OS X!) follow the
earlier Solaris model of persistently storing the
Nevertheless, if there are _any_ scripts that use
it, unless you get
rid of all 29 (or however many) links to it, I
don't see any incremental gain
by removing some of them.
Am taking the conservative approach here by removing
only those
commands which could not possibly return true.
On Tue, 2010-06-08 at 13:03 -0700, Scott Rotondo
wrote:
Several people have pointed out that the harm from
removing these
commands isn't that great because
(a) recent scripts tend not to use this mechanism
to figure out the type
of platform, and
(b) older scripts will still
While this case was approved, with the idea that
these utilities would
be replaced by integrating the GNU plotutils suite,
I'd like to change
direction somewhat.
Specifically, it seems that /contrib is a superior
delivery mechanism
for these tools. I don't believe that there is a
[...]
Therefore, mounts within a non-global zone are
restricted to a
given allowed list of filesystems, as described
in Section 5 and
Section 6. This applies to all mounts not just
lofi ones.
5. New vfs flag VSW_ZMOUNT
The default list of allowed filesystems is based
upon a new
[...]
Allowing lofi devices into non-global zones
introduces a security
issue. Some filesystems (notably UFS) are not
sufficiently protected
against corrupted or maliciously constructed
filesystem images,
which lofi allows the zone root user to modify.
This could
potentially lead to a
su - $USER -c /usr/bin/audioctl (args)
Double quotes around $USER, please. And I hope
that the contents of $USER are trustworthy at that point.
--
This message posted from opensolaris.org
___
opensolaris-arc mailing list
20 matches
Mail list logo
