Effectively, the "ignore" option just ends up recorded in /etc/mnttab for the
mount; I haven't
seen any evidence that it does anything else; and it looks like a very trivial
addition at least to
lofs, and probably to the zero-block filesystems as well. Some commands such as
df that scan /etc/mnt
On 5/1/07, Richard L. Hamilton <[EMAIL PROTECTED]> wrote:
Does anyone see my point about decluttering df, and maybe about the latter
approach being the
cleanest? If so, what would be the best strategy for RFEs/ARC cases: one, two,
or fully broken
out? More to the point, any _objections to tha
> I'd like to draft a proposal to EOF/eliminate the handling of persistent
> kstats. IMO, a kstat should be cleaned up once kstat_destroy() is
> called, unconditionally. (The definition of KSTAT_FLAG_PERSISTENT
> should be left alone, with admonishments against its use.) This does
> m
I tried this conversation once here or on c.u.s some time ago, and don't recall
getting a consensus,
so I think I'll try again.
I for one find it very annoying that there's no way to exclude from df output
all those filesystems
that do not represent real real storage (optionally together with ex
Garrett D'Amore wrote:
So, given this, it is it safe for me to just call mac_{link,tx_notify()
while holding driver locks?
I would recommend that you not do this even though the code appears to
be safe for now. the reason is that you do not know what the notify
callback is going to do. it may
I'm interested in using mac_link_update and mac_tx_update from a few
contexts where I'm currently holding some driver-specific locks. (E.g.
link lock , xmit lock.)
Going over the code, it _appears_ that this is probably safe. It looks
like these routines arrange to use a taskq_dispatch (via
Hi,
On 05/01/07 11:52, Gavin Maltby wrote ...
... total nonsense!
For example, Studio 11 with -xarch=sparcv8plus can generate two
separate 32-bit ld instructions to load a single 64-bit value. An
atomic_load_64(3C) function would be useful to ensure that a single
ldx instruction is used.
Y
A number of drivers export kstats with a special flag,
KSTAT_FLAG_PERSISTENT.
This flag means that the associated kstats live "forever" in the kernel
after creation, they can never be deleted or destroyed.
The upshot of this is that those stats are viewable long after a device
has departed t
I had to do a small rollback of the gate last night by 3 changesets to
fix the incorrect "onnv_64***" tag that was applied by mistake.
cheers,
steve
--
stephen lau // [EMAIL PROTECTED] | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
__
Here is some enhancements to batstat.c that
add the standard usage() and that allows to better understand
the -v output. It now gives also Watthours, Volts and Amperes.
--- batstat.corig Fri Oct 21 13:34:13 2005
+++ batstat.c Tue May 1 14:24:40 2007
@@ -173,6 +173,25 @@
On 04/30/07 22:01, Chris Elving wrote:
[EMAIL PROTECTED] wrote:
If those APIs do what their names suggests, what is the point
in having them?
"Atomic set" can hardly be anything other than a normal store
nor can "Atomic read" be much different from an ordinary read.
I'd find them useful.
> grep /usr/share/man/man9*/*
I suppose a docs.sun.com search of the appropriate man page sections
would be more elegant, _if_ docs.sun.com weren't so darn slow lately.
This message posted from opensolaris.org
___
opensolaris-code mailin
>All I know is that a lot of driver vendors favour them. I know ATi
>used them for a long time with their driver...
For drivers we have all the ddi* functions which access objects of the
proper size "atomically".
Casper
___
opensolaris-code mailing l
13 matches
Mail list logo
