Prev: module: fix __module_ref_addr()
Next: oprofile, perf, x86: introduce new functions to reserve perfctrs by index
From: Alan Cox on 29 Mar 2010 14:30
> 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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 29 Mar 2010 14:40
> What I *really* object to with this patch is that it inherently assumes
> that there is only one multiplexed resource in the entire system... but
> of course nowhere enforces that.

The patch does nothing of the sort. Not unless there is a bug I am not
seeing anyway. It does assume nobody tries to grab pairs of such
resources as it doesn't do deadlock avoidance.

It's now a shared resource patch however, its a multiplexor patch and
that is precisely why it is called MUX not SHARED or OVERLAY
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 29 Mar 2010 15:10
On 03/29/2010 11:39 AM, Alan Cox wrote:
>> What I *really* object to with this patch is that it inherently assumes
>> that there is only one multiplexed resource in the entire system... but
>> of course nowhere enforces that.
>
> The patch does nothing of the sort. Not unless there is a bug I am not
> seeing anyway. It does assume nobody tries to grab pairs of such
> resources as it doesn't do deadlock avoidance.
>
> It's now a shared resource patch however, its a multiplexor patch and
> that is precisely why it is called MUX not SHARED or OVERLAY
> Alan

Sorry, I missed the "continue", which of course handles the situation I
was worried about. The shared wait queue is a bit inelegant, but if it
turns out to be a bottleneck in real life then we either have bigger
problems or it can be addressed at that time.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jesse Barnes on 2 Apr 2010 16:40
On Mon, 29 Mar 2010 19:29:57 +0100
Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote:

> > 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.

Well I'm not sure such over-engineering would be "grand", but it does
seem like overkill for the devices you're covering here. At any rate,
the patch is in my linux-next tree, so it'll head to Linus next merge
cycle unless some big new objections arise.

--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2 3
Prev: module: fix __module_ref_addr()
Next: oprofile, perf, x86: introduce new functions to reserve perfctrs by index