Re: [patch 2/5] Staging: vme: add VME userspace driver

["Emilio G. Cota" <cota@braap.org>]

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.