On 05/28/10 04:57, Frank Batschulat (Home) wrote:
> On Fri, 28 May 2010 10:43:22 +0200, <eiji....@oracle.com> wrote:
>> Hi Frank,
>> getzoneid() can return a correct value even if it's called in a taskq thread
>> (kernel context) and/or in an interrupt handler (interrupt context)?
> I suppose so, look its not doing anything earth shattering:
>    2496 getzoneid(void)
>    2497 {
>    2498       return (curproc->p_zone->zone_id);
>    2499 }
> no locking involved, no allocations done, nothing considered
> harmfull in an interrupt context or taskq thread.
> only question is to what proc your taskq/interrupt thread will bind to.

It sounds like we might need more information about what the original
poster is attempting to do.

Interrupts themselves aren't features of non-global zones, so they're
not normally attributed to any particular zone.  In theory, if there
were devices dedicated to individual zones, you could use the device's
state structure to find the zoneid associated.

If you just use getzoneid() in that context, you'll get the zoneid of
the zone whose thread happens to be pinned down by the interrupt.  In
other words, it's an arbitrary and almost certainly wrong answer.

I think something's amiss if you're asking about zoneid outside the
context of direct system call processing.  The answers there vary quite
a bit.  For example, with STREAMS, the correct answer is to fetch the
cred_t attached to the dblk_t, and get the zoneid from the cred_t.

It's not unusual at all for interrupts and taskqs to do work on behalf
of many different zones, and for them to need to track this information

James Carlson         42.703N 71.076W         <carls...@workingcode.com>
zones-discuss mailing list

Reply via email to