[parisc-linux-cvs] [PATCH] 32-bit PDC wrapper patch

Paul Bame bame@fc.hp.com
Thu, 15 Mar 2001 10:57:48 -0700

= I disagree.  I think it's entirely possible & cleaner to  have the
= individual wrappers (pdc_*) do the argument setup before calling the
= real_call function. [snip]
= The way I look at this is that we have a (relatively) typesafe interface
= which then communicates with the type-unsafe PDC.  The parts which
= know about the type should handle all the checking, then convert into
= unsigned longs which is what PDC accepts.

I like this too, and had it not been for STI and some other "rogue"
uses of mem_pdc_call(), I'd have preferred to have mem_pdc_call()
and the rest of the type-unsafe stuff, safely hidden in pdc.c like
you suggest, or at least have a separate "private" header file if we
keep real1.c around (which might be a good idea for STI and possibly
a PDC ioctl() call in the future).

The current situation has the callers to the pdc_ layer knowing
way too much IMO (like alignment and sometimes phys/virt I think).

= real_call function.  If we are going to keep the varargs, we should
= pass the number of arguments which should be popped off the stack.
= My recollection is that there's no guarantee that calling va_arg for
= more arguments than were passed will work.

Ah I knew there was must be a good reason to avoid varargs as used!