From: Greg KH <greg@kroah.com>
To: "J.E.J. Bottomley" <James.Bottomley@steeleye.com>
Cc: Matthew Wilcox <willy@debian.org>,
"Adam J. Richter" <adam@yggdrasil.com>,
andmike@us.ibm.com, hch@lst.de, 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: Tue, 12 Nov 2002 22:13:10 -0800 [thread overview]
Message-ID: <20021113061310.GD2106@kroah.com> (raw)
In-Reply-To: <200211091533.gA9FXuW02017@localhost.localdomain>
On Sat, Nov 09, 2002 at 10:33:56AM -0500, J.E.J. Bottomley wrote:
>
> > 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.
I was referring to the pci_module_init() model of PCI drivers, which, as
of 2.5.47, is only implemented in the ips, nsp32 and aic7xxx drivers.
Every other PCI SCSI controller driver will crash and burn a nasty death
if placed in a machine with a PCI hotplug controller, and someone tries
to remove it. Hopefully someday this will be fixed... :)
> 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.
All of that sounds very reasonable, and would be nice to see
implemented.
> > 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.
What is the real reason for needing this, pci_alloc_consistent()? We
have talked about renaming that to dev_alloc_consistent() in the past,
which I think will work for you, right?
thanks,
greg k-h
next prev parent reply other threads:[~2002-11-13 6:11 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
2002-11-13 6:13 ` Greg KH [this message]
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=20021113061310.GD2106@kroah.com \
--to=greg@kroah.com \
--cc=James.Bottomley@steeleye.com \
--cc=adam@yggdrasil.com \
--cc=andmike@us.ibm.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).