Re: [parisc-linux] Untested port of parisc_device to generic device interface

From: Greg KH (
Date: Wed Nov 13 2002 - 01:13:10 EST

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

> > 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?


greg k-h
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 22:00:28 EST