On 20/07/12 10:48, Martyn Welch wrote:
> On 19/07/12 23:39, Greg Kroah-Hartman wrote:
>> On Thu, Jul 19, 2012 at 08:08:50PM +0100, Martyn Welch wrote:
> Still in two minds about whether we should keep vme_user around. It does seem
> to have users and there are simple drivers/tasks that could be coded in user
> space using this. On the other hand, the interface to user space it currently
> provides isn't idea, neither is the fact that it grabs 4 VME windows when the
> module is loaded, regardless of whether they ever get used. It was certainly
> useful during development of the VME subsystem, but my focus is really on the
> subsystem and kernel space VME drivers.
vme_user is useful when it comes to porting legacy VME code
to Linux. Having a possibility to access the bus from userland will
surely ease this task, userland is simply more convenient to work
with. If speed is not too important, there's no real need to
involve all the kernel complexity.
Besides the sub-optimal interface, there are some functionalities that
should be exported in addition to what is currently available from
vme_user. I'm working on cleaning up the driver, and would suggest to
adapt the interface as follows:
- Support more than one bridge; place the device files in
/dev/bus/vme/000/... etc., similar to the USB subsystem
- Dynamically query the number of available master/slave windows
from the low-level driver, expose this information to userland,
and don't create access windows on startup, but only when needed.
- Expose the RMW mechanism and semaphores to userland
- Implement a timeout mechanism when waiting for IACKs
- Provide generic/status information (e.g., sysfail, slot id, ...), via
some mechnism (ioctl, sysfs, whatever)
- Possibly map location monitors into userland (interrupt proagation
via uio)
Any comments on these ideas?
A pull request for some changes in this direction is given below.
However, the code is _NOT_ meant to be pulled right now -- the patches
are not yet in shape; some things still need to be implemented and/or
polished. But it could simplify the discussion.
Unfortunately, I cannot do any real tests for a temporary lack of
hardware at the moment. But this should not really concern a general
discussion about the future shape of this driver.
Best, Wolfgang
####################################################################
The following changes since commit 28a33cbc24e4256c143dce96c7d93bf423229f92:
Linux 3.5 (2012-07-21 13:58:29 -0700)
are available in the git repository at:
git://github.com/siemens/vme.git not-yet-for-upstream
Wolfgang Mauerer (16):
Tiny comment fix
Extract VME major number definition from the device driver
vme_user: Clarify buffer allocation comment
vme_user: Get rid of Universe II references
vme_user: Cosmetic fixes
vme_user: Some more context for error messages
vme_user: Indentation cleanups
vme_user: Push ioctl arguments into local scope
vme_user: Add support for sending RMW cycles
vme: Equip irq generation with a timeout
vme_user: Use device_type methods to map per-bridge information into userland
vme_user: Export slot id to userland
tsi148: Allow for exporting the bridge status
ca91c42x: Allow for exporting status information
vme, vme_user: Make bridge status public
vme_user: Simplify ioctl state machine
drivers/staging/vme/devices/vme_user.c | 323 ++++++++++++++++++++------------
drivers/staging/vme/devices/vme_user.h | 24 ++-
drivers/vme/bridges/vme_ca91cx42.c | 10 +-
drivers/vme/bridges/vme_tsi148.c | 43 ++++-
drivers/vme/vme.c | 30 +++-
drivers/vme/vme_bridge.h | 6 +-
include/linux/major.h | 2 +
include/linux/vme.h | 8 +-
8 files changed, 311 insertions(+), 135 deletions(-)
--
Siemens AG, Corporate Technology
Corporate Competence Centre Embedded Linux
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
