All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Mitch Bradley <wmb@firmworks.com>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
	linux-kernel@vger.kernel.org, devel@laptop.org,
	jengelh@linux01.gwdg.de, David Miller <davem@davemloft.net>,
	jg@laptop.org
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem
Date: Wed, 03 Jan 2007 07:48:02 +1100	[thread overview]
Message-ID: <1167770882.6165.76.camel@localhost.localdomain> (raw)
In-Reply-To: <459ABC7C.2030104@firmworks.com>

On Tue, 2007-01-02 at 10:11 -1000, Mitch Bradley wrote:
> 
> > We could of course have the interface work either on a copy of the tree
> > or on a real OF (though that means changing things like get_property on
> > powerpc and fixing the gazillions of users) but I tend to think that
> > working on a copy always is more efficient.
> >
> >   
> The patch that I posted creates a copy in the virtual filesystem 
> domain.  So the efficiency issue is moot.
> 
> The filesystem domain copy is smaller than the in-memory tree, as it 
> omits a lot of unnecessary fields.

"a lot" ? Hrm... et me see... a device-node contains the pointers for
the tree structure and the property list ...

What other fields ? We do have indeed a void * on powerpc which is handy
for the PCI code in there but I might get rid of it at one point and we
have a copy of the phandle which is useful as soon as you try to parse
things like the interrupt-tree.

Now, you can have that, and then have a filesystem capable of
instanciating dentries & inodes on the fly based on that structure (and
thus purge them on memory pressure too. In which case the footprint is
actually smaller since inodes/dentries are big, thus it's a good thing
to be able to purge them and re-create them on the fly.

I do object basically to having something that doesn't also provide
in-kernel interfaces to access the device nodes & properties. I don't
agree with the reasoning that x86 will never need it. Now, we have
currently two slightly different interfaces, on powerpc and sparc, to
access them, and that's I think we should try to converge and use the
same interface for x86.

In addition, as sparc64 also moved to an in-memory copy of the tree, I
tend to be fairly convinced that we should also move toward the same
-implementation- also based on an in-memory copy of the tree which is
more efficient (and doesn't use a significant amount of RAM).
  
Ben.


  reply	other threads:[~2007-01-02 20:48 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-31  1:38 [PATCH] Open Firmware device tree virtual filesystem Mitch Bradley
2006-12-31  5:19 ` David Miller
2006-12-31  9:36   ` Mitch Bradley
2006-12-31  9:52     ` David Miller
2006-12-31 10:11     ` David Kahn
2006-12-31 10:49       ` David Miller
2006-12-31 11:47         ` Rene Rebe
2006-12-31 11:53         ` David Kahn
2007-01-01  3:48           ` Segher Boessenkool
2007-01-02  3:56           ` Benjamin Herrenschmidt
2007-01-02 18:43             ` Richard Smith
2006-12-31 15:41         ` Christoph Hellwig
2006-12-31 20:46           ` David Miller
2007-01-01  3:37             ` David Kahn
2007-01-01  8:54               ` David Miller
2007-01-02  4:02               ` Benjamin Herrenschmidt
2007-01-02 12:28                 ` Segher Boessenkool
2007-01-01  3:33           ` Segher Boessenkool
2007-01-01  8:57             ` David Miller
2007-01-01 17:48               ` Segher Boessenkool
2007-01-01 23:08                 ` David Miller
2007-01-01 23:52                   ` Segher Boessenkool
2007-01-02  3:31                     ` David Miller
2007-01-02 11:26                       ` Segher Boessenkool
2007-01-02  1:40                   ` David Kahn
2007-01-02  3:36                     ` David Miller
2007-01-01 18:10               ` Mitch Bradley
2007-01-01 19:21                 ` Jan Engelhardt
2007-01-02  4:05               ` Benjamin Herrenschmidt
2007-01-02  4:30                 ` David Miller
2007-01-02  4:57                   ` Benjamin Herrenschmidt
2007-01-02  5:01                     ` David Miller
2007-01-02  5:09                       ` Benjamin Herrenschmidt
2007-01-02  5:44                         ` David Miller
2007-01-02 12:36                     ` Segher Boessenkool
2007-01-02 11:03                   ` Segher Boessenkool
2007-01-02  3:53     ` Benjamin Herrenschmidt
2007-01-02 12:22       ` Segher Boessenkool
2007-01-02 20:12         ` Benjamin Herrenschmidt
2007-01-02 21:28           ` Segher Boessenkool
2007-01-02 21:32             ` Benjamin Herrenschmidt
2007-01-02 21:40               ` Segher Boessenkool
2007-01-02 22:10                 ` David Miller
2007-01-02 22:05             ` David Miller
2007-01-03  0:48               ` Segher Boessenkool
2007-01-03  4:34                 ` David Miller
2007-01-03 15:23                   ` Segher Boessenkool
2007-01-04  2:15                     ` David Miller
2007-01-02  3:45   ` Benjamin Herrenschmidt
2007-01-02  3:49     ` David Miller
2007-01-02 11:45     ` Segher Boessenkool
2007-01-02 20:07       ` Benjamin Herrenschmidt
2006-12-31 13:24 ` Pekka Enberg
2006-12-31 18:55   ` Mitch Bradley
2006-12-31 14:12 ` Jan Engelhardt
2006-12-31 20:45   ` David Miller
2006-12-31 21:30     ` Jan Engelhardt
2007-01-02  3:43     ` Benjamin Herrenschmidt
2007-01-02 11:37       ` Segher Boessenkool
2007-01-02 13:22         ` Stefan Reinauer
2007-01-02 20:08         ` Benjamin Herrenschmidt
2007-01-02 20:11           ` Mitch Bradley
2007-01-02 20:48             ` Benjamin Herrenschmidt [this message]
2007-01-02 21:37               ` Segher Boessenkool
2007-01-02 21:47                 ` Benjamin Herrenschmidt
2007-01-03  0:35                   ` Segher Boessenkool
2007-01-03  0:44                     ` Benjamin Herrenschmidt
2007-01-03  1:14                       ` Segher Boessenkool
2007-01-03  4:35                         ` David Miller
2007-01-02 22:07                 ` David Miller
2007-01-03  0:52                   ` Segher Boessenkool
2007-01-03  1:13                     ` Jan Engelhardt
2007-01-03  4:38                       ` David Miller
2007-01-03  5:05                         ` Benjamin Herrenschmidt
2007-01-03 15:59                           ` Segher Boessenkool
2007-01-03 15:31                         ` Segher Boessenkool
2007-01-03  4:34                     ` David Miller
2007-01-02 21:15           ` Segher Boessenkool
2007-01-02 21:59             ` David Miller
2007-01-01  3:40   ` Segher Boessenkool
2007-01-01  4:21 ` Segher Boessenkool
  -- strict thread matches above, loose matches on Subject: below --
2007-01-11 17:39 ron minnich
2007-01-11 17:53 ` Mitch Bradley
2007-01-11 17:55   ` ron minnich
2007-01-11 18:36     ` Segher Boessenkool
2007-01-11 18:20 ` Stefan Reinauer
2007-01-11 18:47   ` Segher Boessenkool
2007-01-11 19:12     ` ron minnich
2007-01-11 19:11   ` ron minnich

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=1167770882.6165.76.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=davem@davemloft.net \
    --cc=devel@laptop.org \
    --cc=jengelh@linux01.gwdg.de \
    --cc=jg@laptop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=segher@kernel.crashing.org \
    --cc=wmb@firmworks.com \
    /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.