Re: so what's so special about sema_init() for alpha?

["Robert P. J. Day" <rpjday@mindspring.com>]

On Fri, 27 Oct 2006, Roman Zippel wrote:

> Hi,
>
> On Tue, 24 Oct 2006, Robert P. J. Day wrote:
>
> >   i'm still curious as to why the implementation for sema_init()
> > for the alpha can't be simplified as (allegedly) could all of the
> > other architecture sema_init() calls.
>
> Did you even look at the code it generates? It's not specific to
> alpha at all. Unless the structure is small enough, gcc will first
> generate a copy on the stack and then copy it to its final location.

i'm sorry, i'm not familiar with the alpha architecture but now i'm
more confused than before.  to recap, i was asking if there was an
actual *reason* why the alpha sema_init() *required* the following
implementation:

======================
static inline void sema_init(struct semaphore *sem, int val)
{
        /*
         * Logically,
         *   *sem = (struct semaphore)__SEMAPHORE_INITIALIZER((*sem),val);
         * except that gcc produces better initializing by parts yet.
         */

        atomic_set(&sem->count, val);
        init_waitqueue_head(&sem->wait);
}
======================

  on the one hand, as i recall, randy dunlap referred to the comment
that "gcc produces better initializing by parts yet" as if that, by
itself, explained the necessity, although it's not clear what that
even means or what relevance it has.

  on the other hand, you seem to be suggesting that there's nothing
alpha-specific about this after all.  and the only reason i'm flogging
this is because, once upon a time, i proposed just simplifying
sema_init() across the board by having all of them just invoke
__SEMAPHORE_INITIALIZER().  i didn't think this was such a big deal,
but that idea has provoked some disagreement, although i'm still
trying to figure out what the technical obstacle is, that's all.

  so to keep things simple, the question remains, can that call be
simplified for the alpha?  yes or no?  that's all i'm looking for.

rday
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/