From: torvalds@transmeta.com (Linus Torvalds)
To: linux-kernel@vger.kernel.org
Subject: Re: Getting FS access events
Date: 15 May 2001 14:12:44 -0700 [thread overview]
Message-ID: <9ds64c$2k0$1@penguin.transmeta.com> (raw)
In-Reply-To: <3B0190F6.9D08D9CE@transmeta.com> <Pine.GSO.4.21.0105151628340.21081-100000@weyl.math.psu.edu>
In article <Pine.GSO.4.21.0105151628340.21081-100000@weyl.math.psu.edu>,
Alexander Viro <viro@math.psu.edu> wrote:
>>
>> How would you know what datatype it is? A union? Making "struct
>> block_device *" a "struct inode *" in a nonmounted filesystem? In a
>> devfs? (Seriously. Being able to do these kinds of data-structural
>> equivalence is IMO the nice thing about devfs & co...)
>
>void *.
No. It used to be that way, and it was a horrible mess.
We _need_ to know that it's an inode, because the generic mapping
functions basically need to do things like
mark_inode_dirty_pages(mapping->host);
which in turn needs the host to be an inode (otherwise you don't know
how and where to write the dang things back again).
There's no question that you can avoid it being an inode by virtualizing
more of it, and adding more virtual functions to the mapping operations
(right now the only one you'd HAVE to add is the "mark_page_dirty()"
operation), but the fact is that code gets really ugly by doing things
like that.
It was an absolute pleasure to remove all the casts of "mapping->host".
With "void *" it needed to be cast to the right type (and you had to be
able to _prove_ that you knew what the right type was). With "inode *",
the type is statically known, and you don't actually lose anything (at
worst, you'd have a virtual inode and then do an extra layer of
indirection there).
I really don't think we want to go back to "void *".
Linus
next prev parent reply other threads:[~2001-05-15 21:13 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200105140117.f4E1HqN07362@vindaloo.ras.ucalgary.ca>
2001-05-14 1:32 ` Getting FS access events Linus Torvalds
2001-05-14 1:45 ` Larry McVoy
2001-05-14 2:39 ` Richard Gooch
2001-05-14 3:09 ` Rik van Riel
2001-05-14 4:27 ` Richard Gooch
2001-05-15 4:37 ` Chris Wedgwood
2001-05-23 11:37 ` Stephen C. Tweedie
2001-05-14 2:24 ` Richard Gooch
2001-05-14 4:46 ` Linus Torvalds
2001-05-14 5:15 ` Richard Gooch
2001-05-14 13:04 ` Daniel Phillips
2001-05-14 18:00 ` Andreas Dilger
2001-05-14 20:16 ` Linus Torvalds
2001-05-14 23:19 ` Richard Gooch
2001-05-15 0:42 ` Daniel Phillips
2001-05-15 4:00 ` Linus Torvalds
2001-05-15 4:35 ` Larry McVoy
2001-05-15 4:57 ` David S. Miller
2001-05-15 5:12 ` Alexander Viro
2001-05-15 9:10 ` Alan Cox
2001-05-15 9:48 ` Lars Brinkhoff
2001-05-15 9:54 ` Alexander Viro
2001-05-15 20:17 ` Kai Henningsen
2001-05-15 20:58 ` Alexander Viro
2001-05-15 21:08 ` Alexander Viro
2001-05-15 4:59 ` Alexander Viro
2001-05-15 17:01 ` Pavel Machek
2001-05-15 4:43 ` Linus Torvalds
2001-05-15 5:04 ` Alexander Viro
2001-05-15 6:20 ` Richard Gooch
2001-05-15 6:28 ` Linus Torvalds
2001-05-15 6:49 ` Richard Gooch
2001-05-15 6:57 ` Alexander Viro
2001-05-15 10:33 ` Daniel Phillips
2001-05-15 10:44 ` Alexander Viro
2001-05-15 14:42 ` Daniel Phillips
2001-05-15 7:13 ` Linus Torvalds
2001-05-15 7:56 ` Chris Wedgwood
2001-05-15 8:06 ` Linus Torvalds
2001-05-15 8:33 ` Alexander Viro
2001-05-15 10:27 ` David Woodhouse
2001-05-15 16:00 ` Chris Mason
2001-05-15 19:26 ` H. Peter Anvin
2001-05-15 20:03 ` Alexander Viro
2001-05-15 20:07 ` H. Peter Anvin
2001-05-15 20:15 ` Alexander Viro
2001-05-15 20:17 ` H. Peter Anvin
2001-05-15 20:22 ` Alexander Viro
2001-05-15 20:26 ` H. Peter Anvin
2001-05-15 20:31 ` Alexander Viro
2001-05-15 21:12 ` Linus Torvalds [this message]
2001-05-15 21:22 ` H. Peter Anvin
2001-05-15 21:02 ` Linus Torvalds
2001-05-15 21:53 ` Jan Harkes
2001-05-19 5:26 ` Chris Wedgwood
2001-05-15 10:04 ` Anton Altaparmakov
2001-05-15 19:28 ` H. Peter Anvin
2001-05-15 22:31 ` Albert D. Cahalan
2001-05-15 22:35 ` H. Peter Anvin
2001-05-16 1:17 ` Anton Altaparmakov
2001-05-16 1:30 ` H. Peter Anvin
2001-05-16 8:34 ` Anton Altaparmakov
2001-05-16 16:27 ` H. Peter Anvin
2001-05-15 16:26 ` Pavel Machek
2001-05-15 18:02 ` Craig Milo Rogers
2001-05-15 16:17 ` Pavel Machek
2001-05-19 19:39 ` Linus Torvalds
2001-05-19 19:44 ` Pavel Machek
2001-05-19 19:47 ` Linus Torvalds
2001-05-23 11:29 ` Stephen C. Tweedie
2001-05-20 4:30 ` Chris Wedgwood
2001-05-20 19:47 ` Alan Cox
2001-05-18 7:55 ` Rogier Wolff
2001-05-23 11:36 ` Stephen C. Tweedie
2001-05-15 6:13 ` Richard Gooch
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='9ds64c$2k0$1@penguin.transmeta.com' \
--to=torvalds@transmeta.com \
--cc=linux-kernel@vger.kernel.org \
/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