The content I got from command line with modinfo is different from the content
I got from MDB -K with ::dmods,is it right?
This message posted from opensolaris.org
___
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensol
Hi!
Does anyone know when the new POSIX-draft versions of |mkdirat()|&co.
(e.g |mkdirat()|, |faccessat()|, |fchmodat()|, |fchownat()|,
|fstatat()|, |linkat()|, |mknodat()|, |openat()|, |symlinkat()|,
|unlinkat()|, |utimensat()|) will be available in Solaris (AFAIK these
functions were added
Garrett D'Amore wrote:
One of the things that I've been asked to look at lately is interrupt
load spreading, and intrd, to improve the network performance of CMT
systems.
From my read of the code, it looks like intrd only knows about virtual
processors. This has major breakage in that all th
One of the things that I've been asked to look at lately is interrupt
load spreading, and intrd, to improve the network performance of CMT
systems.
From my read of the code, it looks like intrd only knows about virtual
processors. This has major breakage in that all the virtual processors
on
...
> OBP behaves for SPARC like the BIOS for x86, right?
more or less.. it's more like BIOS + GRUB all in firmware.
>
> I am trying to figure out what happens now in the
> boot as main calls vfs_mountroot
> (usr/src/uts/common/os/main.c:440), which calls
> rootconf (usr/src/uts/common/fs/vfs.
Thomas De Schampheleire wrote:
I have a related question about setfrontdq():
In my logs I see a lot of calls to this function, without them being
followed by a switch() or resume(). Is it possible that setfrontdq()
itself resumes the task, or is the only function that can resume a
task resume()?
Mirko Cetkovic wrote:
Hello,
I wonder if there is something similar to WInd32 API
FindFirstChangeNotification for ZFS - any API ?
here is example :
http://msdn2.microsoft.com/en-us/library/aa365261.aspx
many thanks
Mipko
A project to add File Event Monitoring to Solaris Event Ports
is curr
Paul Durrant wrote:
On 28/05/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
You should not attempt to acquire a lock which will be held by other
functions calling cv_wait, or its brethren. (There are ways to do that
safely, but it requires a fair bit of effort to make sure you do it
safely.)
Paul Durrant wrote:
On 29/05/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Paul Durrant wrote:
> On 28/05/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
>> You should not attempt to acquire a lock which will be held by other
>> functions calling cv_wait, or its brethren. (There are ways to d
> yes unix is just another partially relocated module
> in
> some ways. krtld gets to initialize almost first, so
> that
> genunix is loaded early and then things in unix can
> call
> things in genunix. That way very little code has to
> be
> aware about the unix/genunix split.
>
> For example, in
> Drivers can be unloaded from memory and then loaded
> back in on demand,
> and when they are reloaded, it'll be from disk.
> Plus, we need the
> bility to check the integrity of the boot archive and
> rebuild if
> necessary. I think removing files from the file
> system and having
> them in the
Paul Durrant wrote:
On 29/05/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Paul Durrant wrote:
> On 28/05/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
>> You should not attempt to acquire a lock which will be held by other
>> functions calling cv_wait, or its brethren. (There are ways to d
On 29/05/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Paul Durrant wrote:
> On 28/05/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
>> You should not attempt to acquire a lock which will be held by other
>> functions calling cv_wait, or its brethren. (There are ways to do that
>> safely, but
Paul Durrant wrote:
On 28/05/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
You should not attempt to acquire a lock which will be held by other
functions calling cv_wait, or its brethren. (There are ways to do that
safely, but it requires a fair bit of effort to make sure you do it
safely.)
On 28/05/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
You should not attempt to acquire a lock which will be held by other
functions calling cv_wait, or its brethren. (There are ways to do that
safely, but it requires a fair bit of effort to make sure you do it safely.)
I was not aware of t
[EMAIL PROTECTED] wrote:
As my understand, cv_wait and its brethren could be called from a
interrupt context, including a soft interrupt context.
For this reason, when people read the timeout(9F), he will think since
timeout handler's context is considered as a soft interrupt context, it
wil
>As my understand, cv_wait and its brethren could be called from a
>interrupt context, including a soft interrupt context.
>For this reason, when people read the timeout(9F), he will think since
>timeout handler's context is considered as a soft interrupt context, it
>will be safe if we called
[EMAIL PROTECTED] wrote:
Garrett D'Amore wrote:
Thomas De Schampheleire wrote:
Hi,
The timeout(9F) manpage says:
"The function called by timeout() must adhere to the same
restrictions as a driver soft interrupt handler.
The function called by timeout() is run in inter
>Garrett D'Amore wrote:
>> Thomas De Schampheleire wrote:
>>> Hi,
>>>
>>> The timeout(9F) manpage says:
>>>
>>> "The function called by timeout() must adhere to the same
>>> restrictions as a driver soft interrupt handler.
>>>
>>> The function called by timeout() is run in interrupt co
19 matches
Mail list logo
