On Sat, 2007-01-27 at 23:16 -0700, Eric W. Biederman wrote:

Michael Ellerman [off-list ref] writes:

quoted

I guess I wasn't clear enough in my original post, but I fully expect
that I'll need to tweak parts of the core to make Intel fit. That's
still a work in progress.

Ok.  To be very clear.

Any plan that does not involve using drivers/pci/msi.c for the
raw hardware operations is flawed.  Yes that code is a mess
but it works today, and appears to capture all of the requirements.
Where there are issues that code should be fixed not ignored.

Which is what I plan to do. I already have a patch which turns the
current code into a backend for my code, its ugly as hell, it maintains
msi_info and the msi_descs which is stupid, but it seems to work.

We should probably just stop talking until I've got that series worked
out and posted, and then you can tell me what you think of it :)

The architecture specific bits of the current msi code roughly
correspond to your alloc and free routines.  All that is
needed going from generic code to architecture specific code
is the ability to allocate and free an msi irq.  You have
a lot more operations than that and it is overkill.

Except you keep ignoring the hypervisor case, which we have to support.
I realise you'd rather not think about it, sure it's ugly, but that's
our reality. We could isolate all of that in arch/powerpc, but Greg has
said he doesn't want two implementations, and I think in the long term
that's the right approach - we should be able to come up with a common
implementation.

As a practical measure you current operations are such a bad fit
for the architectures a port would be very difficult.  Basically
setup_msi_message is simply a bad idea.  You need to use a
write_msi_message call from the architecture to the generic code
instead.

i386's msi_compose_msg() would just become setup_msi_message(), the
setup of the irq chip etc. would go in alloc. For irq affinity, for now
we'll just keep exporting read/write_msi_msg(). But I don't see what the
fundamental problem is.

I have some patches cooking to cleanup msi.c so it can be used
as is.  I'm pretty much their but it looks like I need to slay
msi_lock to make things sane.

If you can post them soon that would be good. I'm already heavily
hacking the intel code to work as a backend for me so anything you do
will conflict with that work.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person