> I'm not sure if this is the right venue for this question.  Does anybody know
> off-hand if kernel stacks are pageable?  Is it safe to create a condition
> variable on a kernel stack?
> _______________________________________________
> opensolaris-code mailing list
> [email protected]
> https://opensolaris.org:444/mailman/listinfo/opensolaris-code

Hi Robert,

Even though kernel stacks are unpageable, it's unsafe to create
a condition variable on a kernel stack. How do you guarantee that
this piece of callflow-local data will not be overwritten/reused
in a later instantiation of a different call sequence using the
same stack ?

You could of course consider doing something like thread_create(),
and then in essence have a (persistent) 'main()'-like function
running that'll stay around 'forever', together with its associated
local data. I.e. if you never unwind the call sequence by returning
to the bottommost function then the unwound part of the stack becomes
"permanent data" - which isn't equivalent to global data but can
technically be made so by providing a way to find its location
(i.e. a pointer to it).

Is that good programming practice ? Definitely not. What you want
to do is to elevate the scope of local variables to global. Yes,
the C language allows you to do such things through the backdoor
but forcing this calls for later trouble.
And it's in no way simpler than doing a kmem_alloc()/cv_init().

I.e. why do you want to what amounts to:

func()
{
        kcondvar_t mycv;
        cv_init(&myvc, NULL, CV_DRIVER, NULL);

        for(;;)
                main_handler_func(&mycv);
}

instead of:

func()
{
        kcondvar_t *mycv = kmem_alloc(sizeof(kcondvar_t), KM_SLEEP);
        cv_init(myvc, NULL, CV_DRIVER, NULL);

        for(;;)
                main_handler_func(mycv);
}

What's the advantage ? You don't save nothing. Typing 30 characters,
maybe. For what ? Purely academic interest ?

I.e. why can't you kmem_alloc (the structure that contains) the condvar ?

Best Regards,
FrankH.

_______________________________________________
opensolaris-code mailing list
[email protected]
https://opensolaris.org:444/mailman/listinfo/opensolaris-code

Reply via email to