linux-kernel - Re: [PATCH 12/14] nubus: Rename struct nubus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 14 Nov 2017 11:18:49 +1100 (AEDT)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
cc:     Linux/m68k <linux-m68k@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Linux Fbdev development list <linux-fbdev@...r.kernel.org>
Subject: Re: [PATCH 12/14] nubus: Rename struct nubus_dev

On Mon, 13 Nov 2017, Geert Uytterhoeven wrote:

> Hi Finn,
> 
> On Sat, Nov 11, 2017 at 7:12 AM, Finn Thain <fthain@...egraphics.com.au> 
> wrote:
> > It is misleading to use "dev" to mean a functional resource. And in 
> > adopting the Linux Driver Model, struct nubus_board will embed a 
> > struct device. Drivers will then bind with boards, not with functional 
> > resources.
> >
> > Rename struct nubus_dev as struct nubus_functional_resource. This is 
> > the vendor's terminology and avoids confusion.
> 
> Isn't "struct nubus_functional_resource" a bit long? 

Right.

> What about "nubus_res"? "nubus_fres"?
> 

I think the temporary variables can remain 'fres', as that's just a 
mnemonic, though the declaration really ought to tell us something 
meaningful.

You and I both avoided 'func' as an abbreviation. I think it suggests a 
'C' function pointer. And 'res' and 'rsrc' suggest an ioport.h struct 
resource. An unambiguous compromise would be 'nubus_functional_rsrc' but 
maybe this is still too long?

Perhaps 'struct nubus_rsrc' or 'struct nubus_res' are okay if we can keep 
the distinction between 'functional resources', 'slot resources' and 
'board resources' clear by naming instances appropriately? E.g.

@@ -33,7 +33,7 @@ struct nubus_dirent {
 
 struct nubus_board {
        struct nubus_board *next;
-       struct nubus_dev *first_dev;
+       struct nubus_rsrc *first_func_rsrc;
 
        /* Only 9-E actually exist, though 0-8 are also theoretically
           possible, and 0 is a special case which represents the
@@ -81,8 +81,8 @@ struct nubus_dev {
        struct nubus_board *board;
 };
 
-/* This is all NuBus devices (used to find devices later on) */
-extern struct nubus_dev *nubus_devices;
+/* This is all NuBus functional resources (used to find devices later on) 
*/
+extern struct nubus_rsrc *nubus_func_rsrcs;
 /* This is all NuBus cards */
 extern struct nubus_board *nubus_boards;

etc.

-- 

> Gr{oetje,eeting}s,
> 
>                         Geert
>