Messages in this thread | | | Date | Fri, 27 Oct 2006 07:42:31 -0400 (EDT) | From | "Robert P. J. Day" <> | Subject | Re: so what's so special about sema_init() for alpha? |
| |
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/
| |