From: Jamie Lokier <lk@tantalophile.demon.co.uk>
To: Andries.Brouwer@cwi.nl
Cc: viro@math.psu.edu, alan@lxorguk.ukuu.org.uk,
linux-kernel@vger.kernel.org, torvalds@transmeta.com
Subject: Re: [RFC] lazy allocation of struct block_device
Date: Sat, 1 Sep 2001 22:26:59 +0100 [thread overview]
Message-ID: <20010901222659.A4089@thefinal.cern.ch> (raw)
In-Reply-To: <200109012042.UAA17644@vlet.cwi.nl>
In-Reply-To: <200109012042.UAA17644@vlet.cwi.nl>; from Andries.Brouwer@cwi.nl on Sat, Sep 01, 2001 at 08:42:20PM +0000
Andries.Brouwer@cwi.nl wrote:
> From viro@math.psu.edu Sat Sep 1 18:26:53 2001
> > A kdev_t is a pointer to a struct that has the info now found in
> > the arrays (and major, minor fields, and a name function..).
> > This struct is allocated by the driver.
>
> Umm... Apply the arguments from the char_device thread - pointers to
> unions are rather bad idea. IOW, kdev_t must die - kernel always
> knows which kind we are dealing with.
>[...]
> However, a union is not so bad. It seems a pity to avoid unions
> and waste 4 bytes for every inode with separate i_bdev and i_cdev
> instead of a single i_bcdev.
Please, a union of different pointer types is much nicer. You can have
i_bdev and i_cdev without wasting any bytes.
This form works with GCC 2.96:
union {
struct char_device * i_cdev;
struct block_device * i_bdev;
};
If you're using a really old compiler that doesn't support anonymous unions,
(GCC 2.95 might be in this category, I'm not sure), then you'll need this:
#define i_bdev __i_bcdev_union.i_bdev
#define i_cdev __i_bcdev_union.i_cdev
union {
struct char_device * i_cdev;
struct block_device * i_bdev;
} __i_bcdev_union;
Either way, you avoid pointers to unions and you also avoid having a
named union type which contains pointers.
-- Jamie
next prev parent reply other threads:[~2001-09-01 21:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-01 20:42 [RFC] lazy allocation of struct block_device Andries.Brouwer
2001-09-01 21:26 ` Jamie Lokier [this message]
2001-09-01 23:41 ` Anton Altaparmakov
2001-09-01 23:54 ` Alexander Viro
-- strict thread matches above, loose matches on Subject: below --
2001-09-02 20:05 Andries.Brouwer
2001-09-02 17:25 Andries.Brouwer
2001-09-02 18:46 ` Alexander Viro
2001-09-02 10:24 Andries.Brouwer
2001-09-02 11:38 ` Alexander Viro
2001-09-02 12:49 ` Alan Cox
2001-09-02 15:38 ` Richard Gooch
2001-09-02 16:07 ` Alexander Viro
2001-09-02 16:16 ` Richard Gooch
2001-09-01 13:30 Andries.Brouwer
2001-09-01 16:26 ` Alexander Viro
2001-08-31 4:43 Alexander Viro
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=20010901222659.A4089@thefinal.cern.ch \
--to=lk@tantalophile.demon.co.uk \
--cc=Andries.Brouwer@cwi.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/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.