Brendan Gregg - Sun Microsystems wrote:
G'Day Darren,
On Mon, Jun 18, 2007 at 10:51:33AM -0700, [EMAIL PROTECTED] wrote:
...
...I'm sure that there is such a thing as too many dtrace
probe points :)
These are near zero overhead when not enabled (some nops plus some movs to
set registers);
G'Day Folks,
The IP providers have evolved into three parts based on the probe name.
Here is an update for each, and a link to a webrev.
1) send/receive and local-send/local-receive probes,
These probes are working well.
# ./ipio01.d
NAME SOURCE DESTBYTES
I should have asked what the intention of the rbridges-dev list
was before jumping to too many conclusions...
James Carlson wrote:
[EMAIL PROTECTED] writes:
If closed membership lists are to be the way of the future
then I have a couple of requests:
* please do *NOT* cc open membership lists
yifan wrote:
yifan wrote:
...
Sounds reasonable to me. How about the second thought, extending
ipfilter rules to be able to specify zone name. Something like:
block in zone z1 ether all
or
block in on zone:z1 ether all
...
It's hard to get zoneid in mac layer. Surely the zone can be sp
> Does anyone know why icmp_bind is called with qwriter() ?
I can't see a reason -- but I have a guess: usually, xxx_bind() has to
find an available port number, which may (and does, in the case of the
early Solaris TCP and UDP implementations) require synchronization with
other module instances
> > > document the driver's private properties correctly after Brussel?
> >
> > Minimally, in the driver's manpage.
>
> Well, documenting private properties is something that needs to be
> done with extreme discretion, becuase private properties are an extremely
> Unstable interface. Ho
> On (06/22/07 18:58), Peter Memishian wrote:
> > But link_speed isn't listed in ieee802.3(5) -- so does this mean we'll use
> > "speed"? More generally, I'm not convinced that reusing those names is
> > the right choice (Do we really want to have a "link_up" property? Or do
>
> right, so
On (06/22/07 18:58), Peter Memishian wrote:
> But link_speed isn't listed in ieee802.3(5) -- so does this mean we'll use
> "speed"? More generally, I'm not convinced that reusing those names is
> the right choice (Do we really want to have a "link_up" property? Or do
>
right, so the decision (i
> > My original thinking (when coming up with show-linkprop for WiFi) was that
> > we could add additional (optional) fields for whatever information we
> > wanted. For instance, we could have a DESC field that gives a short
> > description of the property, or whatever. The most commonly use
On (06/22/07 18:06), Peter Memishian wrote:
> > It would be useful to have some additional information about the property
> > (for example, a pointer to the ieee802.3(5) man page for adv_autoneg_cap),
> > but clearly, there is not much room left in the output above, if we
> > assume the standa
Sorry for being late to this thread.
> It would be useful to have some additional information about the property
> (for example, a pointer to the ieee802.3(5) man page for adv_autoneg_cap),
> but clearly, there is not much room left in the output above, if we
> assume the standard 80 char wi
[EMAIL PROTECTED] wrote:
On (06/22/07 10:26), Garrett D'Amore wrote:
Why not have mac_prop_lookup go to the DDI properties on behalf of the
driver? (In other words, instead of going up to some daemon, if the daemon
isn't present, just use the driver.conf properties.)
What I'm getting at i
On (06/22/07 10:26), Garrett D'Amore wrote:
>
> Why not have mac_prop_lookup go to the DDI properties on behalf of the
> driver? (In other words, instead of going up to some daemon, if the daemon
> isn't present, just use the driver.conf properties.)
>
> What I'm getting at is, this detail, can
On (06/22/07 08:37), Garrett D'Amore wrote:
>
> The upshot of this, is that I think it makes sense to consider the
> following approach. Please let me know your thoughts:
>
>Consider a brussels strategy of "importing" initial values from DDI
>properties. (I.e. look first there for initi
[EMAIL PROTECTED] wrote:
On (06/22/07 08:37), Garrett D'Amore wrote:
The upshot of this, is that I think it makes sense to consider the
following approach. Please let me know your thoughts:
Consider a brussels strategy of "importing" initial values from DDI
properties. (I.e. look f
[EMAIL PROTECTED] wrote:
On (06/20/07 11:21), Erik Nordmark wrote:
Brussels properties will be available when the driver attaches: early on
in the xxx_attach routine, each converted driver will invoke dladmd with a
door_upcall and persistent properties will be loaded up in the kernel
for th
[EMAIL PROTECTED] writes:
> If closed membership lists are to be the way of the future
> then I have a couple of requests:
> * please do *NOT* cc open membership lists when sending
> email to them - we get bounces about "cannot send email"
There are folks who are on the project team mailing list
On (06/20/07 11:21), Erik Nordmark wrote:
>
>> Brussels properties will be available when the driver attaches: early on
>> in the xxx_attach routine, each converted driver will invoke dladmd with a
>> door_upcall and persistent properties will be loaded up in the kernel
>> for the driver as part
[EMAIL PROTECTED] wrote:
On (06/20/07 11:21), Erik Nordmark wrote:
[EMAIL PROTECTED] wrote:
Brussels properties will be available when the driver attaches: early on
in the xxx_attach routine, each converted driver will invoke dladmd with a
door_upcall and persistent properties will be loa
19 matches
Mail list logo
