[lkml]   [2001]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: How should nano_sleep be fixed (was: ptrace(), fork(), sleep(), exit(), SIGCHLD)
    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:57    [W:0.024 / U:47.472 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site