The Linux kernel coding style guidelines suggest not using typedefs for
structure types. This patch gets rid of the typedefs for cfs_wi_sched.
Also, the name of the struct is changed to drop the _t, to make the name
look less typedef-like.
The following Coccinelle semantic patch detects the case:
@tn@
identifier i;
type td;
@@
-typedef
struct i { ... }
-td
;
@@
type tn.td;
identifier tn.i;
@@
-td
+ struct i
Signed-off-by: Shraddha Barke <shraddha.6...@gmail.com>
---
drivers/staging/lustre/lustre/libcfs/workitem.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/workitem.c
b/drivers/staging/lustre/lustre/libcfs/workitem.c
index 48009b7..02d18f5 100644
--- a/drivers/staging/lustre/lustre/libcfs/workitem.c
+++ b/drivers/staging/lustre/lustre/libcfs/workitem.c
@@ -45,7 +45,7 @@
#define CFS_WS_NAME_LEN 16
-typedef struct cfs_wi_sched {
+struct cfs_wi_sched {
struct list_head ws_list; /* chain on global list
*/
/** serialised workitems */
spinlock_t ws_lock;
@@ -73,7 +73,7 @@ typedef struct cfs_wi_sched {
unsigned int ws_starting:1;
/** scheduler name */
char ws_name[CFS_WS_NAME_LEN];
-} cfs_wi_sched_t;
+};
static struct cfs_workitem_data {
/** serialize */
@@ -87,19 +87,19 @@ static struct cfs_workitem_data {
} cfs_wi_data;
static inline void
-cfs_wi_sched_lock(cfs_wi_sched_t *sched)
+cfs_wi_sched_lock(struct cfs_wi_sched *sched)
{
spin_lock(&sched->ws_lock);
}
static inline void
-cfs_wi_sched_unlock(cfs_wi_sched_t *sched)
+cfs_wi_sched_unlock(struct cfs_wi_sched *sched)
{
spin_unlock(&sched->ws_lock);
}
static inline int
-cfs_wi_sched_cansleep(cfs_wi_sched_t *sched)
+cfs_wi_sched_cansleep(struct cfs_wi_sched *sched)
{
cfs_wi_sched_lock(sched);
if (sched->ws_stopping) {
@@ -221,7 +221,7 @@ EXPORT_SYMBOL(cfs_wi_schedule);
static int
cfs_wi_scheduler (void *arg)
{
- struct cfs_wi_sched *sched = (cfs_wi_sched_t *)arg;
+ struct cfs_wi_sched *sched = (struct cfs_wi_sched *)arg;
cfs_block_allsigs();
--
2.1.0
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
