public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Brian J. Murrell" <8db422baa67bd7a698f50768bba0d47e@interlinx.bc.ca>
To: linux-mtd@lists.infradead.org
Cc: joern@wohnheim.fh-wedel.de, Jamey.Hicks@hp.com
Subject: Re: MTD Config.in items not escaped by bus availability
Date: Wed, 30 Oct 2002 15:49:37 -0500	[thread overview]
Message-ID: <20021030204937.GG27880@pc.ilinx> (raw)
In-Reply-To: <20021030201608.GA28523@wohnheim.fh-wedel.de>

[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]

On Wed, Oct 30, 2002 at 09:16:08PM +0100, Jörn Engel wrote:
> 
> Usually, the list is a bit slow. My worst delay was a couple of days.

Actually, no, this is a hard (550) bounce.  I have e-mailed the
postmaster but got nothing back yet.

> Correct, uml does not have a memory bus. But it does have memory and
> it does have block devices, which can both be used to create mtd
> devices from.

OK, I must be mis-understanding what an MTD device is then, not
surprisingly.  Which is precicely why I came and asked here about
this.  I had assumed that an MTD was the likes of a Compact Flash card
/PCMCIA memory device and the like.  Some physical piece of memory
hardware device that required physical connection to the machine.

Can you elaborate on how an MTD could be used by a UML kernel?  Is
this similar to using loopback devices to access files as block
devices?  i.e. virtual MTD devices.

So the MTD subsystem will build and run on a UML (i.e. it has no
hardware properties such as IRQ's, DMA, etc. itself)?  Surely there
must be some aspect of the MTD system which becomes dependent on
addressing specific hardware devices though?

Perhaps the test for specific hardware required to support MTD devices
needs to be finer grained than around the whole CONFIG_MTD option.
Something more like:

      <ask about CONFIG_MTD>
if [ "$CONFIG_MEMORY_BUS" = "y" -o
      "$CONFIG_SOME_OTHER_BUS" = "y" -o
      "$CONFIG_YET_ANOTHER_BUS" = "y" ]; then
      <ask about device specific MTD options>
fi

with different test for different kinds of buses specific to each type
of hardware MTD.

> You can say, it already is. But 
> 
> [ "$CONFIG_MEMORY_BUS" = "y" -o
>   "$CONFIG_HAS_MEMORY" = "y" -o
>   "$CONFIG_HAS_BLOCK_DEVICES" = "y" ]
> 
> evaluates to true for all current platforms, including uml.

Are you saying this is how it is already and it is correct?  How can
you attribute a memory bus to UML?  Block devices, I can understand,
in that there are some UML provided block devices like UBD disks etc.

> Your turn, can you still think of a system that doesn't allow for mtd?

I dunno.  I don't know much about MTD, which is why I am asking for
advice here.  Are there any CONFIG_*_MTD* options in the kernel that
need to be protected by any bus options?

-- 
Brian J. Murrell

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2002-10-30 23:48 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-30 16:22 MTD Config.in items not escaped by bus availability Hicks, Jamey
2002-10-30 17:30 ` Brian J. Murrell
     [not found] ` <20021030185507.GA31547@wohnheim.fh-wedel.de>
2002-10-30 19:38   ` Brian J. Murrell
     [not found]     ` <20021030201608.GA28523@wohnheim.fh-wedel.de>
2002-10-30 20:49       ` Brian J. Murrell [this message]
     [not found]         ` <20021030214341.GC25383@wohnheim.fh-wedel.de>
2002-10-30 22:46           ` Brian J. Murrell
2002-10-31 16:53             ` Jörn Engel
2002-10-31 18:37               ` Jörn Engel
2002-10-31 19:05                 ` Brian J. Murrell
2002-10-31 21:00                   ` Jörn Engel
2002-11-03 11:59                 ` Brian J. Murrell
2002-11-04 14:17                   ` Jörn Engel
2002-11-04 14:29                     ` Brian J. Murrell
2002-11-04 17:13                       ` Jörn Engel
2002-11-06 20:45                         ` Brian J. Murrell
2002-11-07  8:00                           ` David Woodhouse
2002-11-07 13:50                             ` Brian J. Murrell
2002-11-07 14:00                               ` David Woodhouse
2002-11-07 15:33                                 ` Jörn Engel
2002-11-07 15:34                                   ` David Woodhouse
2002-11-07 15:54                                     ` Jörn Engel
2002-11-07 15:58                                       ` David Woodhouse
2002-11-07 16:00                                         ` Jörn Engel
2002-11-07 15:21                               ` Jörn Engel
2002-11-07 12:13                         ` Unable to handle kernel NULL pointer dereference at virtual address 0000000c nur
  -- strict thread matches above, loose matches on Subject: below --
2002-10-30 22:09 MTD Config.in items not escaped by bus availability Hicks, Jamey
2002-10-28 13:48 Brian J. Murrell

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=20021030204937.GG27880@pc.ilinx \
    --to=8db422baa67bd7a698f50768bba0d47e@interlinx.bc.ca \
    --cc=Jamey.Hicks@hp.com \
    --cc=joern@wohnheim.fh-wedel.de \
    --cc=linux-mtd@lists.infradead.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