linux-kernel - any value to "struct configfs

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>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0612030534070.2710@localhost.localdomain>
Date:	Sun, 3 Dec 2006 05:43:21 -0500 (EST)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: any value to "struct configfs_attribute" anymore?

  as a followup to my previous patch submission, is there any value to
the definition of "struct configfs_attribute" in configfs.h anymore,
given a similar structure in sysfs.h?

configfs.h:
-----------

struct configfs_attribute {
        const char              *ca_name;
        struct module           *ca_owner;
        mode_t                  ca_mode;
};

sysfs.h:
--------

struct attribute {
        const char              * name;
        struct module           * owner;
        mode_t                  mode;
};

  if these two structs are *necessarily* identical, then it would make
sense to remove the few remaining uses of the former and replace them
with references to the latter, no?  there are only a few files that
appear to still make reference to the former:

fs/configfs/inode.c
fs/ocfs2/cluster/heartbeat.c
fs/ocfs2/cluster/nodemanager.c
fs/dlm/config.c

so standardizing on the latter would be fairly easy.  or is there a
reason why those two structures still have to be treated
independently?

rday
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/