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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090812093949.GB2604@braap.org>
Date:	Wed, 12 Aug 2009 11:39:49 +0200
From:	"Emilio G. Cota" <cota@...ap.org>
To:	Martyn Welch <martyn.welch@...anuc.com>
Cc:	Greg K-H <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	devel@...uxdriverproject.org,
	Sebastien Dugue <sebastien.dugue@...l.net>
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/