mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: torvalds@transmeta.com (Linus Torvalds)
To: linux-kernel@vger.kernel.org
Subject: Re: Getting FS access events
Date: 15 May 2001 14:02:29 -0700	[thread overview]
Message-ID: <9ds5h5$2i6$1@penguin.transmeta.com> (raw)
In-Reply-To: <3B018EF3.F9DF7207@transmeta.com> <Pine.GSO.4.21.0105151621350.21081-100000@weyl.math.psu.edu>

In article <Pine.GSO.4.21.0105151621350.21081-100000@weyl.math.psu.edu>,
Alexander Viro  <viro@math.psu.edu> wrote:
>On Tue, 15 May 2001, H. Peter Anvin wrote:
>
>> Alexander Viro wrote:
>> > >
>> > > None whatsoever.  The one thing that matters is that noone starts making
>> > > the assumption that mapping->host->i_mapping == mapping.
>> > 
>> > One actually shouldn't assume that mapping->host is an inode.
>> > 
>> 
>> What else could it be, since it's a "struct inode *"?  NULL?
>
>struct block_device *, for one thing. We'll have to do that as soon
>as we do block devices in pagecache.

No, Al. It's an inode. It was a major mistake to ever think anything
else.

I see your problem, but it's not a real problem.  What you do for block
devices (or anything like that where you might have _multiple_ inodes
pointing to the same thing, is to just create a "virtual inode", and
have THAT be the one that the mapping is associated with.  Basically
each "struct block_device *" would have an inode associated with it, to
act as a anchor for things like this. 

What is "struct inode", after all? It's just the virtual representation
of a "entity". The inodes associated with /dev/hda are not the inodes
associated with the actual _device_ - they are just on-disk "links" to
the physical device. 

[ Aside: there are good arguments to _not_ embed "struct inode" into
  "struct block_device", but instead do it the other way around - the
  same way we have filesystem-specific inode data inside "struct inode"
  we can easily have device-type specific data there.  And it makes a
  whole lot more sense to attach a mount to an inode than it makes to
  attach a mount to a "struct block_device".

  Done right, we could eventually get rid of "loopback block devices".
  They'd just be inodes that aren't of type "struct block_device", and
  the index to "struct buffer_head" would not be <block_deve *, blknr,
  size>, but <inode *, blknr, size>. See? The added level of indirection
  is one that we actually already _use_, it's just that we have this
  loopback device special case for it..

  In a "perfect" setup you could actually do "mount -t ext2 file /mnt/x"
  without having _any_ loopback setup or anything like that, simply
  because you don't _need_ it. It would be automatic. ]

		Linus

  parent reply	other threads:[~2001-05-15 21:03 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 ` 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: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 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  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  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
2001-05-15 21:22                                     ` H. Peter Anvin
2001-05-15 21:02                                 ` Linus Torvalds [this message]
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  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='9ds5h5$2i6$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

all inboxes | Powered by JetHome®