[lkml]   [2008]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjectsupervising, text processing, semantic "patching" (Re: [JANITOR PROPOSAL] Switch ioctl functions to ->unlocked_ioctl)
    Nice start, Paolo, really!

    I'd recommend to start supervising all this effort, if you wish to
    participate. This doesn't require C knowledge at all, not every sw
    manager shall have lang:c [+]. But you will save other's valuable time
    and effort spent. Also you will eliminate rude and sucking comments like

    If you know how to make simple "unlocked_ioctl progress" web page for that
    on wiki, and to look after it, please do so on site.

    For now i see on the list following:

    Mathieu Segaud, Sergio Luis:
    'PCI: change procfs'

    Andre Noll:
    'drivers/scsi/sg.c to unlocked_ioctl'

    Kevin Winchester:
    'drivers/char/drm to use .unlocked_ioctl'

    Nikanth Karthikesan:
    'drm_ioctl as an unlocked_ioctl'
    'x86 Machine check handler to use unlocked_iocl'
    'paride driver to use unlocked_ioctl'
    'Random number driver: make random_ioctl as an unlocked_ioctl'

    Also you can make a "Tools" section there, where experience and tools
    may be presented. This knowledge may improve future source tree
    processing efforts, and save one's time and bandwidth (searching
    archives, wrong patches, etc.) as well.

    I refer to the _text_ processing tools and techniques, i'm going to
    present below (skip it guys, if you don't like it).

    == Tools ==

    As discussions show, knowledge of C doesn't mean solving this task at
    all. Even worse, one may re-factor/change functions in the way they like,
    but maintainers don't. Compile-time "testing" is a distraction from the
    cause. Note, however, that my vision of the root also may have some flaws.

    Documentation and tutorials. While i'm willing to help in any technical
    things, i know, please look at this first:

    "UNIX Power Tools" is a must (without perl part).
    Keywords: kernel, shell, BRE, sed.

    So, expressions. Let's see on the error you've made. This is not a C
    error at first, this is an expression error:

    Paolo Ciarrocchi @ Tue, 8 Jan 2008 21:03:13 +0100:

    >> > -static const struct file_operations rtc_fops = {
    >> > +static long rtc_fioctl(struct file_operations rtc_fops)
    >> > +{
    >> > + lock_kernel();
    >> > .owner = THIS_MODULE,
    >> You should probably restrict yourself to files that you can at least
    >> compile ...
    > Yes of course, I've been silly in didn't verify whether the file compile
    > but I would appreciate to know whether I'm on the right track or not.

    what you've did is introducing more special symbols, to say least.
    This often leads to definition and meaning changes, rather than
    execution (locks, flow) ones.

    While C is not easy to understand generally, basic things, like functions
    and structs with good coding style, as Linux has, are quite

    So what key thing(s) that can make expression of a function? This are
    braces '(', ')', but see [0] for more.


    Based on that one can `grep` for functions easily[1] (kind of).


    Globally defined structs OTOH are storage things, and usually they are
    initialized with '='. What make expression for them easy is that block
    ('{', '}') is usually started inline with declaration, while it is
    accepted coding style for Linux, that functions have blocks started
    from the new line.

    Thus, it's obvious that special symbols are key things in building of
    expressions and recognizing constructs.

    Let's consider [1].

    1) multiline declarations/definitions are not easy to `grep`
    2) proposed method have problems with all things, that can appear from
    the start of the string to the '(', i.e. returing of pointers '*',
    __attiributes__ '((', '"', etc. (you never now).
    3) similar patterns can be inside
    3.1) multiline comment blocks
    3.2) multiline macro definitions
    *) add yours

    = =
    # find linux-style function definitions (lang:C)
    # Time-stamp: "Thu Mar 6 12:59:10 CET 2008 olecom@flower"

    sed -n '
    # 3.1: /* skip one line comment (for multiline to work) */

    # 3.1: /* skip multiline comment
    # inside can be anything, that match a function */

    # 3.2: skip multiline macros (they generate noise)
    # TODO: find function-generating macros

    # function definition; ends with ")", "," or is like
    # "int foo(int pabar) { return 0; }"
    /^[^[:blank:]{].*[),}]$/{ # 2: look at the end of the line
    /,$/{ # 1: multiline param. block
    /;$/b; # skip declarations (ends with ";")
    s=[)}]$=&= ; t_end ; b_start
    # post-processing
    ## make inline
    /\n/s-\n[[:blank:]]*- -g
    ## remove inline body
    /}$/s- *{.*--
    p}' "$@"

    This script addresses all cases, but not a returning type, if it is on
    prev. line.

    == semantic buzzwords ==

    I saw a [C]"semantic patch" in the janitor list. Don't know if `sed` can
    beat it, but at least, it's not a x86 3M binary blob and without any
    configuration files. But i'm sure, that sooner or later, scripting or
    semantic source code precessing on the git's side will be inevitable
    (automatic audit, yet another check-style, *switch imagination*).

    With some kind of special web site or effort to have reviewed regular
    expressions, IMHO it will be much more easier to move forward, than to
    invent `perl` stuff over and over again (cleanpatch, cleanfile,, unifdef.c, etc.).

    Syntax is hard, yes, especially without syntax highlighting even in
    cool 20 years old GNU Emacs. But it is like assembly, and assembly is
    language of The Kernel Hackers[3].


    > Switching to a different file now...

    Hope you like this start. Maybe i will do all additional stuff for
    "unlocked_ioctl" case:

    * identifying need of the change,
    * lock / unlock in all return variants,
    * changing in-kernel users of the changed functions,
    * testing with existing manual patches.

    But this is very unlikely in case of lack of conversations and curiosity
    (at least).

    > --
    > 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

    We still (after 13 years) don't know how to use mailng lists, do we?
    #oo'L O
    <___=E M

     \ /
      Last update: 2008-03-06 15:37    [W:0.030 / U:21.648 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site