Re: code cleanup

From: Alex Lyashkov (shadow_at_psoft.net)
Date: 04/29/04

  • Next message: Alan Cox: "Re: VM wiring fixed"
    To: John Baldwin <jhb@FreeBSD.org>
    Date: Thu, 29 Apr 2004 07:06:43 +0300
    
    

    , 28.04.2004, 22:41, John Baldwin :
    > On Wednesday 28 April 2004 02:26 pm, Julian Elischer wrote:
    > > On Wed, 28 Apr 2004, John Baldwin wrote:
    > > > On Wednesday 28 April 2004 02:26 am, Alex Lyashkov wrote:
    > > > > Hi All
    > > > >
    > > > > how i see many points at kernel work with allproc list direct, but
    > > > > proc.h introduce macros FOREACH_PROC_IN_SYSTEM.
    > > > > This patch clean this places.
    > > >
    > > > I'd actually rather see the FOREACH_PROC macro removed, I don't think
    > > > hiding the fact that it's a TAILQ is all that useful.
    > >
    > > it makes it possible (well, easier) to do:
    > >
    > > FOREACH_PROC_IN_SYSTEM(p) {
    > > FOREACH_KSEGROUP_IN_PROC(p, kg) {
    > > FOREACH_THREAD_IN_GROUP(kg.td) {
    > > something(td, kg);
    > > }
    > > }
    > > }
    > >
    > > Which is a lot easier to read and understand
    > > than the expanded version. You don't kave to remember the linkage
    > > pointer's names and you can add debugging to it
    > > and check that the correct loks are held etc.
    > > (the latter being a major reason I did it).
    >
    > Note that the allproc_lock protects the allproc list. W/o the FOREACH_PROC
    > macro, I can grep for 'allproc' in the source tree to find all users to
    > verify locking, etc. With the extra macro, I now have to do multiple greps.
    two greps is multiple ? first of FOREACH_PROC, second allproc or combine
    at one grep with two -e parameters.

    > When you multiple the effect with several wrapper macros, it now becomes much
    > more work to work on locking the lists of structures since you have to do
    > multiple greps to find the places to look at. I think remembering the
    > linkages for lists is actually quite important to avoid using the same
    > linkage for multiple lists incorrectly.
    you wrong.
    it`s code from linux kernel, but illustrate who create more readable
    code with macros same as FORAEACH_PROC_IN_SYSTEM.
    ==========================
            read_lock(&in_dev->lock);
            for_primary_ifa(in_dev) {
                    if (inet_ifa_match(a, ifa)) {
                            if (!b || inet_ifa_match(b, ifa)) {
                                    read_unlock(&in_dev->lock);
                                    return 1;
                            }
                    }
            } endfor_ifa(in_dev);
            read_unlock(&in_dev->lock);
    ==========================
    where difficult for find locking problem? but using macro allow write
    more readable code.

    Other argument for this patch - FreeBSD already have this macro and src
    need change to even code.

    -- 
    Alex Lyashkov <shadow@psoft.net>
    PSoft
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
    

  • Next message: Alan Cox: "Re: VM wiring fixed"

    Relevant Pages

    • Re: code cleanup
      ... This macro seemed more reasonable when it was added because its scope ... I now have to do multiple greps. ... > more work to work on locking the lists of structures since you have to do ... > linkage for multiple lists incorrectly. ...
      (freebsd-current)
    • Re: code cleanup
      ... With the extra macro, I now have to do multiple greps. ... more work to work on locking the lists of structures since you have to do ... linkage for multiple lists incorrectly. ...
      (freebsd-current)
    • Re: IA64 .CALL_LINKAGE problem
      ... >> I believe the definition is wrong for this linkage. ... The compiler dies. ... fix the $IA64_LINKAGE macro. ... corrected linkage defs so I don't see to much issue with fixing my macro ...
      (comp.os.vms)