public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Francois Romieu <romieu@cogenit.fr>
Cc: Krzysztof Halasa <khc@pm.waw.pl>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] HDLC patch for 2.5.5 (0/3)
Date: Wed, 20 Feb 2002 08:51:10 -0500	[thread overview]
Message-ID: <3C73A9CE.932BF06F@mandrakesoft.com> (raw)
In-Reply-To: <20020217193005.B14629@se1.cogenit.fr> <m3zo27outs.fsf@defiant.pm.waw.pl> <20020218143448.B7530@fafner.intra.cogenit.fr> <m34rkdohu7.fsf@defiant.pm.waw.pl> <20020220143922.A13224@fafner.intra.cogenit.fr>

Francois Romieu wrote:
> 
> Krzysztof Halasa <khc@pm.waw.pl> :
> [...]
> > Now... You just want to introduce an artificial struct which contains
> > only the union... Why?
> 
> Copy-paste abuse.
> 
> > We could use just the union instead (?).
> 
> Yes. I'll try that tonite.
> 
> [...]
> > Yes, the compiler would compile that. Anyway, don't you think it's
> > a little messy? Void * pointers are IMHO not that evil.
> 
> Once the union in a struct disappears it should be minimal.
> 
> Regarding void * against union/union * I feel like minimal type checking is
> better than none.

Agreed... the more type checking you can provide, the better.

Note that if it is possible to avoid the union in a manner that follows
the VFS inode cleanup, feel free to that too...  Basically each private
info struct looks like

	struct foo_inode {
		/* ... driver-private stuff here ... */
		struct inode vfs_inode;	/* last member of struct */
	};

Making it the last member of the structure ensures that people are not
tempted to do gross typecasting based on assumptions that the
"superclass" type is always located at the beginning of the subclass
substructure.  (I don't know how well that applies to this case, just a
suggestion...)

	Jeff


-- 
Jeff Garzik      | "Why is it that attractive girls like you
Building 1024    |  always seem to have a boyfriend?"
MandrakeSoft     | "Because I'm a nympho that owns a brewery?"
                 |             - BBC TV show "Coupling"

  reply	other threads:[~2002-02-20 13:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-17 18:30 [PATCH] HDLC patch for 2.5.5 (0/3) Francois Romieu
2002-02-17 23:22 ` Jeff Garzik
2002-02-20  1:32   ` Linus Torvalds
2002-02-20 12:15     ` Jeff Garzik
2002-02-21 23:52       ` Krzysztof Halasa
2002-02-22  0:57         ` Jeff Garzik
2002-02-18 12:09 ` Krzysztof Halasa
2002-02-18 13:34   ` Francois Romieu
2002-02-19 11:02     ` Krzysztof Halasa
2002-02-20 13:39       ` Francois Romieu
2002-02-20 13:51         ` Jeff Garzik [this message]
2002-02-20 23:15           ` [PATCH] HDLC patch for 2.5.5 (updated) Francois Romieu

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=3C73A9CE.932BF06F@mandrakesoft.com \
    --to=jgarzik@mandrakesoft.com \
    --cc=khc@pm.waw.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=romieu@cogenit.fr \
    /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