All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J.A. Magallon" <jamagallon@able.es>
To: Albert Cahalan <albert@users.sf.net>
Cc: linux-kernel mailing list <linux-kernel@vger.kernel.org>,
	mort@bork.org, viro@parcelfarce.linux.theplanet.co.uk,
	bluefoxicy@linux.net
Subject: Re: struct task_struct -> task_t
Date: Wed, 21 Jan 2004 11:05:17 +0100	[thread overview]
Message-ID: <20040121100517.GA15918@werewolf.able.es> (raw)
In-Reply-To: <1074642648.828.40311.camel@cube> (from albert@users.sf.net on Wed, Jan 21, 2004 at 00:50:48 +0100)


On 01.21, Albert Cahalan wrote:
> Martin Hicks writes:
> > On Mon, Jan 19, 2004 at 10:24:34PM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> >> On Mon, Jan 19, 2004 at 02:17:57PM -0800, john moser wrote:
> 
> >>> It has come to my attention that in some places
> >>> in the kernel, 'struct task_struct' is used; and
> >>> in others, 'task_t' is used.  Also, 'task_t' is
> >>> 'typedef struct task_struct task_t;'.
> >>>
> >>> I made a small script to change around as much
> >>> as I could so that everything uses task_t,
> >>
> >> What the fsck for?  If anything, the opposite
> >> (and removal of that typedef) would be preferable.
> >
> > John,
> >
> > As Al is trying to point out, we try to discourage
> > the use of typedefs in the kernel.  It is much
> > easier to see that blah_t is really a struct if
> > we always use 'struct blah'.
> 
> That's no good for variable usage. We don't
> write "struct current".
> 
> You're giving the argument for Hungarian
> notation. Not that I'd suggest it, but that
> is where your argument leads.
> 
> IMHO, we type too much already.
> 

At least, don't be redundant.
If you want explicit struct, let the type be 'struct task'
(ie, kill the second _struct).
If you want to use struct types as the rest of types, typedef
a task_t.
But 'struct task_struct' is redundand, long and ugly.

-- 
J.A. Magallon <jamagallon()able!es>     \                 Software is like sex:
werewolf!able!es                         \           It's better when it's free
Mandrake Linux release 10.0 (Cooker) for i586
Linux 2.6.1-jam4 (gcc 3.3.2 (Mandrake Linux 10.0 3.3.2-4mdk))

  reply	other threads:[~2004-01-21 10:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-20 23:50 struct task_struct -> task_t Albert Cahalan
2004-01-21 10:05 ` J.A. Magallon [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-01-19 22:17 john moser
2004-01-19 22:24 ` viro
2004-01-19 23:57   ` Martin Hicks

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=20040121100517.GA15918@werewolf.able.es \
    --to=jamagallon@able.es \
    --cc=albert@users.sf.net \
    --cc=bluefoxicy@linux.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mort@bork.org \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.