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

[Matthew Wilcox]

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.