mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Pranith Kumar <pranith.hacks@gmail.com>
Cc: greg@kroah.com, linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [TRIVIAL][PATCH 1/1] Fix warning in staging/otus/ioctl.c
Date: Mon, 08 Jun 2009 20:01:10 +0200	[thread overview]
Message-ID: <4A2D51E6.6030607@s5r6.in-berlin.de> (raw)
In-Reply-To: <4A2CE1A6.9000501@gmail.com>

Pranith Kumar wrote:
> Stefan Richter wrote:
...
>> This code uses defined types which are foreign to Linux.  We don't
>> define UCHAR in Linux.  /This/ needs to be fixed in the entire driver.
>> Until this is not done, there is no reason to add this pointer type cast
...
> Thanks for your comment. Going through the header, I found the following
> defines
> 
> typedef unsigned char		UINT8;
> typedef unsigned short		UINT16;
...
> Now if I delete all these defines and do a search and replace for those
> types, is it OK?
> 
> There might be an argument that the current state is much cleaner. 

Plain C's unsigned char and friends should be preferred.  Pointer types 
like PVOID should be replaced by straight-forward "void *" and so on, 
and BOOLEAN can be replaced by "bool" (with "true" and "false" as 
possible values).

In cases where the particular size of variables or struct members 
matters, there are u8, s16 etc. available.

Furthermore, when variables don't represent CPU endian (host endian) 
data but actually big endian or little endian, then we annotate the 
types with __be32, __le32 etc..  *However*, adding these endian 
annotations (*if* the driver in question has to deal with endianess 
other than CPU) should usually better be done in another separate patch 
or series of patches.  This is because the process of adding the endia 
annotations has a chance of unveiling sloppy or non-protable or even 
buggy code, and then some more intensive and non-trivial work on the 
code will be required.

Lastly, if there is a binary interface to userspace (e.g. character 
device file interface), then we use types like __u32 in header files 
which are going to be used by userspace programs.

Now, the type replacement will of course shuffle the text flow (line 
lengths...), so the question will arise whether to adjust whitespace 
(line wraps) in the same patch set.  However, the code which you looked 
at also has other trivial deviations from kernel style.  Notably, the 
use of CamelCase names rather than all-lowercase with underscores. 
Example:  Something like pClonedPkt should become p_cloned_pkt or better 
p_cloned_packet or cloned_packet (if the p prefix didn't mean anything 
else than that it was a pointer), or if it is clear from context, 
something brief like cp.

Such style adjustments also need to happen; if you are interested in 
doing that, then you can plan ahead and hold off with whitespace 
adjusting changes (indentation, line wraps...) until after you did those 
other changes regarding type names and variable/ function/ macro names.

In any case, before starting some bigger style adjustments, check the 
TODO file of the respective staging driver and notify Greg and 
devel@linuxdriverproject.org, so that clashes with ongoing work by 
others can be avoided.

Moreover, you should probably _not_ start such work on wireless drivers 
in staging like rt2860.  See the notes in the TODO files of these 
drivers; the real work is going on at other drivers for the same 
hardware in the normal Linux wireless development tree.
-- 
Stefan Richter
-=====-==--= -==- -=---
http://arcgraph.de/sr/

  reply	other threads:[~2009-06-08 18:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-08  7:19 Pranith Kumar
2009-06-08  8:08 ` Pranith Kumar
2009-06-08  9:09   ` Stefan Richter
2009-06-08 10:02     ` Pranith Kumar
2009-06-08 18:01       ` Stefan Richter [this message]
2009-06-08 18:18         ` Stefan Richter
  -- strict thread matches above, loose matches on Subject: below --
2009-05-29  7:54 Pranith Kumar
2009-06-02 21:47 ` Greg KH
2009-06-03  6:49   ` Pranith Kumar
2009-06-03 15:21     ` Greg KH
2009-06-04  5:53       ` Pranith Kumar
2009-06-04 17:56         ` Greg KH
2009-06-05  5:10           ` Pranith Kumar
2009-06-05  6:15             ` Pranith Kumar
2009-06-04 18:37         ` Miguel Ojeda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A2D51E6.6030607@s5r6.in-berlin.de \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pranith.hacks@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®