lkml.org 
[lkml]   [2009]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] scripts/checksyscalls.sh: only whine perf_counter_open when supported
    On Sun, Jun 14, 2009 at 05:55:44AM -0400, Mike Frysinger wrote:
    > On Sun, Jun 14, 2009 at 05:37, Paul Mundt wrote:
    > > On Sat, Jun 13, 2009 at 06:48:52AM -0400, Mike Frysinger wrote:
    > >> On Fri, Jun 12, 2009 at 07:29, Mike Frysinger wrote:
    > >> > If the port does not support HAVE_PERF_COUNTERS, then they can't support
    > >> > the perf_counter_open syscall either. ??Rather than forcing everyone to add
    > >> > an ignore (or suffer the warning until they get around to implementing
    > >> > support), only whine about the syscall when applicable.
    > >> >
    > >> > Signed-off-by: Mike Frysinger <vapier@gentoo.org>
    > >>
    > >> Andrew: could you pick this up since Ingo acked it now ?
    >
    > btw, Sam said he would pick it up via the kbuild tree
    >
    > > I fail to see why this is necessary? cond_syscall() takes care of this in
    > > the not implemented case, the same as every other syscall backing some
    > > feature that has yet to be implemented.
    >
    > i dont think we should go hassling every arch maintainer when a new
    > syscall is added that requires arch-specific support for optional
    > features (especially when said features are debug in nature). if
    > wiring up the syscall is the only work because the code is all common
    > (like the pread/pwrite functions), then np of course.

    Perhaps not, but I do prefer to have the script whine at me when a new
    syscall pops up, just so I know when I have to start caring about a new
    feature. New syscalls that are handled by cond_syscall() are trivially
    dropped in to the syscall table to get rid of these warnings, regardless
    of whether you have any intention of really supporting the feature or
    not. If a generic implementation becomes available, then it can be
    supported without having to backtrack and update place-holders.

    These are not things I want to see silenced just because you don't
    presently feel compelled to wire up the entry on your platform.

    The fact the perf counter stuff has no real generic support, or even the
    present infrastructure to support it on pretty much every 32-bit platform
    that isn't x86 is more an issue with -tip development methodology than
    anything to do with the syscall bits.

    Of course if it had been handled properly then the generic software
    counters would have been actually implemented generically and
    subsequently made available from the stub and the HAVE_xxx would be
    reserved for architecture-specific counters. Unfortunately these days
    "generic" generally seems to imply "can be made generic if someone else
    bothers to actually do the work, assuming they can find any documentation
    in the first place".


    \
     
     \ /
      Last update: 2009-06-14 12:15    [W:2.744 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site