Re: semtimedop() support on s390/s390x

Ernie Petrides (petrides@redhat.com)
Tue, 01 Jul 2003 15:11:53 -0400


On Monday, 30-Jun-2003 at 15:6 EDT, Pete Zaitcev wrote:

> > Date: Mon, 30 Jun 2003 14:33:28 -0400
> > From: Ernie Petrides <petrides@redhat.com>
>
> > On Friday, 27-Jun-2003 at 23:5 EDT, Pete Zaitcev wrote:
>
> > > > +- if (call <= SEMCTL)
> > > > ++ if (call <= SEMTIMEDOP)
> > > > switch (call) {
> > > > + case SEMTIMEDOP:
> > >
> > > I guess this is the reason for the ENOSYS. Good catch!
> >
> > Thanks ... there's no substitute for actual testing. :)
> >
> > That odd "switch-optimization" sequence in the s390x compat code
> > is also in several 2.5.73 (....) architectures, but none of
> > them have yet implemented semtimedop() support:
> >
> > h8300, m68k, m68knommu, sh, sparc, sparc64
> >
> > They'll all hit the same problem if/when they ever do semtimedop().
>
> What do folks think about the attached patch, then?
>
> Linus was making noises that he wishes to throttle "cleanups",
> and this is a cleanup. But still... It's contained in arch code.
> I'm pretty sure I can slip it in quietly if there's a sense
> it is likely to save us the same problem in the future.
>
> Also, I hate "<=" irrationally for some reason. I always
> use "<" and ">=". This has something to do with programming
> in pseudo-code and compiling by hand. On some brain-dead CPUs
> and with some data types it is a better comparison.
>
> I'll replicate to s390 and see if s390 -S output changes
> if the source level looks ok to Martin's & Ulrich's eyes.
>
> -- Pete

Actually, what I called the "odd switch-optimization sequence" is in
fact a lose-lose. To clean up the code, the 3 "switch" constructs
that are guarded by 3 "if" statements should be merged into a single
conventional "switch". On s390, this would reduce the code size by
96 bytes and only increase the .rodata section size by 88 bytes. So,
there would be a minor memory savings, more efficient code execution,
and more maintainable source code.

Cheers. -ernie
-
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/