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: <20100329192957.0aa66eaa@lxorguk.ukuu.org.uk>
Date:	Mon, 29 Mar 2010 19:29:57 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Giel van Schijndel <me@...tis.eu>,
	Hans de Goede <hdegoede@...hat.com>,
	Jean Delvare <khali@...ux-fr.org>,
	Jonathan Cameron <jic23@....ac.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Bjorn Helgaas <bjorn.helgaas@...com>,
	Dominik Brodowski <linux@...inikbrodowski.net>,
	Laurens Leemans <laurens@...nips.com>,
	lm-sensors@...sensors.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] resource: shared I/O region support

> Well that does keep it simple, and with just one user that's probably
> best.
> 
> But why not use the common bus driver method?  Muxing at the resource
> level only seems to solve part of the problem...  It doesn't guarantee
> for example that driver A does something to a shared region that breaks
> driver B; it just makes sure they don't access the same region at the
> same time.

The obvious reason for not doing that kind of grand over-engineering is
that you are assuming the devices involved are remotely related. On quite
a few systems we have a collection of superio config interfaces on random
low ports all with their own lock/unlock rituals. They range from
parallel devices to watchdogs and god knows what else. Right now we have
various bits of driver code (parport is a good one) that exist on a cross
fingers, pray and poke model. It would be nice to fix that.

For most super I/O devices the muxing is basically a glorified chip select
line. There isn't any structure to impose over it. Where you have
structure there are better ways to do it, but one does not exclude the
other.

Alan
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ