Victor Yodaiken wrote:
>
> On Fri, Aug 17, 2001 at 11:25:42AM -0700, george anzinger wrote:
> > >
> > How about something like:
> >
> > In ../asm/signal.h (for i386)
> >
> > #define PT_REGS_ENTRY(type,name,p1_type,p1, p2_type,p2) \
> > type name(p1_type p1,p2_typ p2)\
> > { struct pt_regs *regs = (struct pt_regs *)&p1;
>
> In RTLinux we define MACHDEPREGS as an arch dependent type. PPC defines
> this as a pointer and x87 as the structure etc. The small number of functions
> that actually need to manipulate this can be made machine dependent too.
> Came in handy during the port to BSD too.
Uh..? I though that was what I was allowing. It seems to me to be a
lot of extra work to put the same code in 15 different archs.
Especially if one does not really know each of them, nor can any one
group (or individual) be expected to be able to test (or even have the
hardware to test) each of them.
This said, what I am trying to define is a way to write common code that
will handle each arch as the arch coder defines the macro for his arch.
In the given case, for example, the type of the arch dependent structure
is _only_ used in the macros which are defined in the asm/*.h file. In
this particular case, the common macros, (which the arch macros over
ride) do not call the arch dependent function, but assume that it
returns true. For nano_sleep, this means that it will return early on
ptrace signals, a standard violation, but what the current code does,
so each arch can fix their system by defining the macro. I also would
like a way to avoid writing (and supporting) 15 different nano_sleeps,
clock_nano_sleeps, etc.
If I miss understand what you are saying, please help me to understand
it. But do keep in mind, that I _really_ don't want to support 15
incarnations of nano_sleep and clock_nano_sleep. I would, however, like
to find a simple and elegant way to write and support the one common
nano_sleep and clock_nano_sleep, or what ever code.
George
-
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/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:25 EST