Messages in this thread | | | Date | Sat, 9 Nov 2002 03:37:19 +0000 | From | Matthew Wilcox <> | Subject | Re: [parisc-linux] Untested port of parisc_device to generic device interface |
| |
On Fri, Nov 08, 2002 at 05:28:05PM -0800, Adam J. Richter wrote: > To start with, here is another completely untested patch that > I haven't even tried to compile that attempts to port the parisc device > type to the generic device model. I have deliberately not included any > changes that would make it dependent on my generic DMA routine facility.
Actually I think the generic device model is crap. It's failed to live up to its promise of removing common fields from structs, it's introduced a new composite filesystem and it's not helped in any concrete way.
Just look at pci_dev:
struct pci_dev { struct list_head global_list; /* node in list of all PCI devices */ struct list_head bus_list; /* node in per-bus list */ struct pci_bus *bus; /* bus this device is on */ struct pci_bus *subordinate; /* bus this device bridges to */ struct proc_dir_entry *procent; /* device entry in /proc/bus/pci */
unsigned int devfn; /* encoded device & function index */ struct pci_driver *driver; /* which driver has allocated this devic e */ void *driver_data; /* data private to the driver */ struct device dev; /* Generic device interface */ struct resource resource[DEVICE_COUNT_RESOURCE]; /* I/O and memory regio ns + expansion ROMs */ struct resource dma_resource[DEVICE_COUNT_DMA]; struct resource irq_resource[DEVICE_COUNT_IRQ]; char name[90]; /* device name */ }
(there may be some more duplicate fields i've missed)
here's the duplicate fields in struct device:
struct device { struct list_head g_list; /* node in depth-first order list */ struct list_head node; /* node in sibling list */ struct list_head bus_list; /* node in bus's list */ struct list_head driver_list; struct list_head children; struct list_head intf_list; struct device * parent; char name[DEVICE_NAME_SIZE]; /* descriptive ascii string */ char bus_id[BUS_ID_SIZE]; /* position on parent bus */
spinlock_t lock; /* lock for the device to ensure two different layers don't access it at the same time. */ atomic_t refcount; /* refcount to make sure the device * persists for the right amount of time */
struct bus_type * bus; /* type of bus device is on */ struct device_driver *driver; /* which driver has allocated this device */ void *driver_data; /* data private to the driver */ }
Oh, and _that_ embeds a struct kobject:
struct kobject { char name[KOBJ_NAME_LEN]; atomic_t refcount; struct list_head entry; struct kobject * parent; struct subsystem * subsys; struct dentry * dentry; };
For fucks sake, this is ridiculous. I haven't dared compare the relative sizes of struct pci_dev between 2.5, 2.4 and 2.2, but this is sheer bloat.
I was hoping for something _incredibly_ simple from struct device. Something to replace pci_alloc_consistent with device_alloc_consistent. Something where I could look through the ancestors of a device to find out whether it was under a CCIO or just a processor. Something I could query to find out whether it was an EISA, a GSC or a PCI device.
I'm disappointed this is trying to serve the needs of USB over the needs of busses in the box. I don't think it was even remotely smart to unify USB with other busses. And I think the PCI system has suffered the most. I guess I'm so annoyed because I thought it might solve problems instead of increasing the amount of user eyecandy.
> One question about the machine that has no consistent memory > option: does it take PCI cards? If so, then all PCI device drivers > should theoretically use something like wback_fake_consistent. > If not, then it sounds like the facility needs only to apply to > generic DMA operations for "parisc" bus cards.
The only machines which can take any kind of PCI devices that don't have consistent memory available to them are the T-class machines. We have no plans to support these machines. What you do need to watch out for are machines such as the 735/755 which can take an NCR720 chip in a non-coherent memory machine. It is of course also used in machines which are perfectly capable of allocating consistent memory (whether through uncached mappings or a cache-coherent IO TLB).
-- Revolutions do not require corporate support. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |