On Mon, Jan 5, 2009 12:45PM, nico wrote:
> On Mon, Jan 05, 2009 at 09:16:28AM -0800, David
> Bustos wrote:
> > Quoth Richard L. Hamilton on Sat, Jan 03, 2009 at
> 09:19:16AM -0800:
> > > Looking at the method script for the sar service
> (as of snv_97), I see that
>
> > > BTW: Does Solaris/x86 support something like
> marking certain pages as
> > > non-cacheable (for example in some cases it may
> be nice to turn caching
> > > off if the traffic caused by cache coherency (or
> even the plain usage of
> > > cache lines for data which are only read or
> written
> > I've stumbled across some mentions about this, but
> no real details.
> > What's this project about and what are the grand
> plans, if you're
> > allowed to disclose them?
>
> VM2 is a project to redesign the Solaris virtual
> memory system around
> modern computer architectures. The core of
> Peter,
>
> > Have you tried to delete the swap device?
>
> I don't think you will be able to do this. I have a
> very old and faint memory that when swap is
> established at boot
> time, that some memory is immediately swapped/paged
> out, or some space in the swap device is immediately
> allo
[...]
> Hence, I totally agree with...
>
> >If a reasonably stable filesystem-like interface was
> available for
> >prtconf-like data, it would be easy to build tools
> which would look at
>
> >configuration and then subscribe to kstats to
> produce correlated
> >activities, just like prstat doe
>One question to consider is do we want to also
> support something similar to Linux's
> "/proc/cpuinfo"?
"something similar" might be up for discussion, but it's been
said before that unlike Linux, /proc on Solaris is _not_ a dumping
ground for every random piece of system info (worse yet, presen
In PL/1, in addition to regular pointer variables, there were also "area"
variables and "offset" variables. The idea being that it didn't matter where
an area started, because all the offset variables were relative to the start
address.
You could do the same thing in C, declaring e.g.
unsigned ch
[...]
> The interfaces will be based on the event ports
> interfaces. If there is
> a commonly
> used API, like the Linux's 'inotify' we could provide
> that using a library.
[...]
>From what I've read, in terms of what they do, there's perhaps room for
two APIs: one like gamin (as a superset of
For the case of mkfile it doesn't really matter, but AFAIK zfs provides more
guarantees than ufs does. Ufs without logging guarantees very little (esp.
if more or less synchronous metadata updates are turned off e.g. with fastfs).
Ufs with logging more or less guarantees filesystem consistency (an
Well, just to push things a bit, I tried creating a shared object consisting of
#include
#Include
int pipe(int *filedes)
{
return socketpair(AF_UNIX,SOCK_STREAM,0,filedes);
}
compiling it as
cc -c -K pic -G pipe_as_socket.c
ld -lsocket -lnsl -G -o pipe_as_socket.so pipe_as_socket.o
and LD
However, it appears a pipe _is_ a STREAM in Solaris, so I'd expect
getmsg(2)/putmsg(2) should work; not the same, but perhaps similar enough,
although some of the features are obscure or at least lacking in examples,
unless you're wealthy enough to afford the appropriate book(s) by Stevens (or
Tee
11 matches
Mail list logo
