[lkml]   [2003]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: The disappearing sys_call_table export.

    [Alan Cox]
    >> 10. kernel patches are impractical, I must be able to do this with std
    >> stock, redhat, AND suse kernels.

    > So you want every vendor to screw up their kernels and the base kernel
    > for an obscure (but fun) corner case. Thats not a rational choice is it.
    > You want "performance is everything" you pay the price, don't make
    > everyone suffer.

    Hmm. sys_call_table is gone? That's sad.

    How about a


    and displaying a nasty warning message on the console whenever a
    module used it?

    It is rare that I need to use it, but when I do I need it bad, for instance:

    fsync on large files used to have severe performance problems, I was
    able to just change sys_fsync to be a call to sys_sync without
    rebooting or even restarting the database(Solid) before the problem
    got out of hand.

    A server for an online internet game had several months of uptime and
    I needed to rotate the log-files so I made a module which trapped
    sys_write and closed and reopened the file with a new name before

    Even if it is discouraged for normal use it is a very nice thing to
    have to fix up various surprises.

    I know I can still use the Phrack technique, but somehow I am not
    convinced that I can rely on it being available.

    - Terje

    [1] When I do this kind of thing now I do:
    (gdb) attach 9597
    (gdb) call close(7)
    (gdb) call open("out.txt",0100 | 01, 0666 )
    (gdb) cont

    This did not work back then however.
    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 13:35    [W:0.020 / U:1.580 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site