From: "J.E.J. Bottomley" <James.Bottomley@steeleye.com>
To: Greg KH <greg@kroah.com>
Cc: Matthew Wilcox <willy@debian.org>,
"Adam J. Richter" <adam@yggdrasil.com>,
andmike@us.ibm.com, hch@lst.de, James.Bottomley@SteelEye.com,
linux-kernel@vger.kernel.org, mochel@osdl.org,
parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] Untested port of parisc_device to generic device interface
Date: Sat, 09 Nov 2002 10:33:56 -0500 [thread overview]
Message-ID: <200211091533.gA9FXuW02017@localhost.localdomain> (raw)
In-Reply-To: Message from Greg KH <greg@kroah.com> of "Fri, 08 Nov 2002 22:03:42 PST." <20021109060342.GA7798@kroah.com>
First off, lets remember that this discussion started over two different, but
related, problem sets. One was the DMA api and the other was the device model.
As far as the DMA API goes, consistent memory allocation has always annoyed me
because there are three separate cases
1. machine is consistent, consistent allocation always succeeds (unless we're
out of memory)
2. machine is fully inconsistent, consistent allocation always fails.
3. Machine is partially consistent. consistent allocation may fail because
we're out of consistent memory so we have to fall back to the old.
What I'd like is an improvement to the DMA API where drivers can advertise
levels of conformance (I only work with consistent memory or I work correctly
with any dma'able memory and do all the sync points), and where all the sync
point stuff optimises out for a machine architecture which is recognisably
fully consistent at compile time.
Ok, I'll get off my soapbox now. I never quite recovered from the awful
#ifdef mess that doing the above correctly for the parisc introduced into the
53c700 driver...
As far as the device model goes:
greg@kroah.com said:
> No, lets start pulling stuff out of pci_dev and relying on struct
> device. The reason this hasn't happened yet is no one has been
> willing to break all of the PCI drivers, yet.
I'd like to see that. It's always annoyed me that my MCA machines have to
bounce highmem just because they don't have a pci_dev to put the bounce mask
in.
> The SCSI people are being drug kicking and screaming into it,
> _finally_ now (hell, SCSI is still not using the updated PCI
> interface, those people _never_ update their drivers if they can avoid
> it.)
That't not entirely fair. Most of the unbroken drivers in the tree (those
with active 2.5 maintainers) are using the up to date pci/dma interface. The
mid layer is `sort of' using the device api.
Where I'd like to see the device model go for SCSI is:
- we have a device node for every struct scsi_device (even unattached ones)
- unattached devices are really minimal entities with as few resources
allocated as we can get away with, so we can have lazy attachment more easily.
- on attachment, the device node gets customised by the attachment type (and
remember, we can have more than one attachment).
- whatever the permanent `name' field for the device is going to be needs to
be writeable from user level, that way it can eventually be determined by the
user level and simply written there as a string (rather than having all the
wwn fallback cruft in the mid-layer).
- Ultimately, I'd like us to dump the host/channel/target numbering scheme in
favour of the unique device node name (we may still number them in the
mid-layer for convenience) so that we finesse the FC mapping problems---FC
devices can embed the necessary identification in the target strings.
- Oh, and of course, we move to a hotplug/coldplug model where the root device
is attached in initramfs and everything else is discovered in user space from
the boot process.
> Patches for this stuff are going to be happening for quite some time
> now, don't despair.
> And they are greatly appreciated, and welcomed from everyone :)
As far as extending the generic device model goes, I'll do it for the MCA bus.
I have looked at doing it previously, but giving the MCA bus a struct pci_dev
is a real pain because of the underlying assumptions when one of these exists
in an x86 machine.
But, while were on the subject of sorting out the device model abstraction,
does the `power' node entry really belong at the top level? It serves no
purpose for something like a legacy MCA bus.
James
next prev parent reply other threads:[~2002-11-09 15:27 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-09 4:51 [parisc-linux] Untested port of parisc_device to generic device interface Adam J. Richter
2002-11-09 5:21 ` Matthew Wilcox
2002-11-09 6:03 ` Greg KH
2002-11-09 15:33 ` J.E.J. Bottomley [this message]
2002-11-13 6:13 ` Greg KH
2002-11-13 7:46 ` Miles Bader
2002-11-13 7:52 ` Greg KH
2002-11-13 8:02 ` Miles Bader
2002-11-13 8:10 ` Greg KH
2002-11-13 8:26 ` Miles Bader
2002-11-13 8:25 ` Greg KH
2002-11-13 9:05 ` Miles Bader
[not found] ` <miles@lsi.nec.co.jp>
2002-11-13 20:13 ` Grant Grundler
2002-11-13 20:21 ` J.E.J. Bottomley
2002-11-13 20:37 ` Grant Grundler
2002-11-13 11:59 ` Ivan Kokshaysky
2002-11-13 12:36 ` Marc Zyngier
2002-11-13 16:32 ` Bjorn Helgaas
2002-11-13 17:23 ` J.E.J. Bottomley
2002-11-13 20:33 ` Grant Grundler
2002-11-13 20:44 ` J.E.J. Bottomley
2002-11-13 21:42 ` Grant Grundler
2002-11-13 20:12 ` Grant Grundler
2002-11-09 7:58 ` Marc Zyngier
2002-11-09 18:04 ` Grant Grundler
-- strict thread matches above, loose matches on Subject: below --
2002-12-18 3:01 [RFT][PATCH] generic device DMA implementation James Bottomley
2002-12-18 3:13 ` David Mosberger
2002-12-28 18:14 ` Russell King
2002-12-28 18:19 ` James Bottomley
2002-12-04 17:47 [RFC] " James Bottomley
2002-12-04 18:27 ` Jeff Garzik
2002-12-04 19:36 ` James Bottomley
2002-12-04 21:19 ` Miles Bader
2002-12-04 21:21 ` Miles Bader
2002-12-04 21:42 ` James Bottomley
2002-12-05 5:44 ` Miles Bader
2002-12-04 21:46 ` James Bottomley
2002-12-05 2:31 ` Miles Bader
2002-12-05 3:06 ` James Bottomley
2002-12-05 5:02 ` David Gibson
2002-12-05 11:15 ` Benjamin Herrenschmidt
2002-12-05 11:16 ` William Lee Irwin III
2002-12-05 15:12 ` James Bottomley
2002-12-05 0:47 ` David Gibson
2002-12-05 0:54 ` Jeff Garzik
2002-12-05 1:44 ` James Bottomley
2002-12-05 2:38 ` David Gibson
2002-12-05 3:13 ` James Bottomley
2002-12-05 5:05 ` David Gibson
2002-12-05 15:03 ` James Bottomley
2002-12-05 23:54 ` David Gibson
2002-12-05 3:17 ` Miles Bader
2002-12-05 6:06 ` David Gibson
2002-12-05 6:43 ` Miles Bader
2002-12-05 23:44 ` David Gibson
2002-12-06 2:23 ` Miles Bader
2002-12-05 3:41 ` Jeff Garzik
2002-12-05 6:04 ` David Gibson
2002-12-05 16:29 ` Jeff Garzik
2002-12-05 23:59 ` David Gibson
2002-12-05 11:08 ` Benjamin Herrenschmidt
2002-12-05 11:35 ` Russell King
2002-12-05 15:24 ` James Bottomley
2002-12-06 0:01 ` David Gibson
2002-11-10 5:20 [parisc-linux] Untested port of parisc_device to generic device interface Adam J. Richter
2002-11-10 1:50 Adam J. Richter
2002-11-10 0:23 Adam J. Richter
2002-11-10 2:01 ` J.E.J. Bottomley
2002-11-10 2:15 ` Matthew Wilcox
2002-11-09 12:22 Adam J. Richter
[not found] <200211090128.RAA31693@adam.yggdrasil.com>
2002-11-09 3:37 ` Matthew Wilcox
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=200211091533.gA9FXuW02017@localhost.localdomain \
--to=james.bottomley@steeleye.com \
--cc=adam@yggdrasil.com \
--cc=andmike@us.ibm.com \
--cc=greg@kroah.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@osdl.org \
--cc=parisc-linux@lists.parisc-linux.org \
--cc=willy@debian.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;
as well as URLs for NNTP newsgroup(s).