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:
2498 return (curproc->p_zone->zone_id);
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.
p0 or zsched ? p0 will always deliver the GLOBAL_ZONEID (zone0)
>> > I'm wondering if there is a way to get a zoneid from kernel even though
>> > it's not in user context. If it's possible, this is useful for us to
>> > activate an HCA port in the exclusive-IP zone at boot time.
>> > Here's the background info.
>> > Currently the IP path info is gotten when the driver is attached, then
>> > an HCA port can be ready for RDSv3, but this way is for the global zone,
>> > and it doesn't work well for the exclusive-IP zone because the driver
>> > cannot
>> > get the zoneid when it's attached (so far). After all, we have to wait
>> > until
>> > customers run a command for RDSv3 in the zone, but the port should be ready
>> > at boot time w/o any customers' actions. It'd be better off getting it
>> > in the driver attach, but I don't know if it's possible.
>> > If it's not possible to get a zoneid from kernel if it's not in user
>> > context,
>> > then is there any recommended method to get it at boot time? I'm thinking
>> > maybe by using SMF, we can invoke an appropriate command (like ifconfig) at
>> > boot time to activate HCAs in the exclusive-IP zones, but if there is a
>> > proper
>> > way for this kind of purpose, that'd be better.
>> for kernel consumers use:
>> #include <sys/zone.h>
>> 473 extern zoneid_t getzoneid(void);
It is always possible to agglutinate multiple separate problems
into a single complex interdependent solution.
In most cases this is a bad idea.
zones-discuss mailing list