Messages in this thread |  | | | Date | Wed, 12 Aug 2009 11:39:49 +0200 | | From | "Emilio G. Cota" <> | | Subject | Re: [patch 2/5] Staging: vme: add VME userspace driver |
| |
Martyn Welch wrote: > So it's foolish to have a generic USB layer, or a generic PCI layer or > generic "name you bus here" layer? [ snip ] > Or it could be layered on top, utilising the the resource management > that I have proposed and the two can sit together happily > side-by-side. > If you are right and that method of access works best, then drivers > will > use that rather than requesting resources. If not then the two can > continue to sit side-by-side. Why make the bridge drivers more complex > than they need to be?
aagh, please stop this nonsense.
http://lwn.net/Articles/336262/ "Here we see the first reason to dislike midlayers - they encourage special cases. When writing a midlayer it is impossible to foresee every possible need that a bottom level driver might have, so it is impossible to allow for them all in the midlayer. The midlayer could conceivably be redesigned every time a new requirement came along, but that is unlikely to be an effective use of time. Instead, special cases tend to grow."
I won't discuss this anymore.
> Unless you provide a consistent API, such as one supporting the features > documented in the VME specifications, how are you planning to write > drivers that could potentially work on more than one specific bridge? [ snip ] > Also, it seems that your API doesn't currently support Location > Monitors. These are specified in the VME spec, I'd be interested in > how > you plan to support this feature in a consistent manner with your > current API
What I intend to provide is a sane environment to work with VME devices. The first step is to cover the needs of most use cases:
- 1 master Single Board Computer (SBC) running Linux - All the other slots have slave devices in them. These devices are controlled by kernel drivers on the SBC. - The SBC does DMA, direct I/O access (mapping) to/from the slaves, and handles interrupts from the devices.
Once that's settled we could discuss about further parts of the spec. But really today getting the above right is _much_ more important than location monitors support.
E.
|  |