ollie lho ollie@sis.com.tw writes:
On Tue, 2003-07-22 at 13:49, Eric W. Biederman wrote:
For the rest who haven't looked so closely. Greg and Ron are taking the existing superio model and generalizing it.
I have taken the existing pci device model and generalized it.
And now we have the design review/fight/slug out as we meet in the middle.
I suspect the union of the two sets of functions from struct device_operations and from the superio side is two high. But the way forward is to get that union and have everyone understand the pieces backwards and forwards.
I still don't see the point of the dispute. In the PCI model, you make the operations (functions) a separated entity and in the superio model, the operations are embedded in the data structure. Is there any fundamental or design conflict between these two ?
Fundamentally no. And things should work out ok.
The was a point earlier today where things were not meeting in the middle as they should. So the comprehension or the communication that needed to be there, at least appeared absent.
It was especially aggravated by the fact, that I am gone the rest of the week, and the situation could have continued to the point where it would be nasty to put the pieces back together.
My impression of the flow of development is that I asked for some static devices structures for the pci devices, since Ron and Greg are reworking the configuration files. And what I got was the a generalized version of the superio complete with methods.
The ideas have been discussed in the past on this list and I thought I had communicated clearly. Given that my vision and Ron and Greg's have not yet meshed. It is clear that the communicate was not as clear as I thought. The only way I see to make this clear is for people to start using the code. And putting the two halves together.
Then I can give constructive criticism, on the small details.
For me this is sort of like when I was pushing the ELF file format for the payload. Until it happened and I had the code in place people just didn't see it.
From working with it, Stefan, Yhlu, and I seem to have a pretty good
grasp of how to make the dynamic side of it work, at least for the easy things. Ron and Greg seem to have a good feel for the dynamic side. But we haven't merged the two so there is no good global feel for things yet.
So until the static and the dynamic pieces are fit together feel that it is ineffective and inappropriate to talk about little details of the design. I will talk about what needs to happen to glue the two pieces together (An appropriate enumerate_static_devices method).
So what you see is much more pent of design discussion and frustration than actual conflict.
The goals of the design are lofty. - A universal hardwaremain.c that can be used on multiple architectures. - A device architecture that handles both static and dynamic devices. - Clear requirements from the methods so things fit together cleanly and intuitively instead of a weird mish mash that just happens to work.
We have a pretty good position on the basic architecture, a device tree. But refining it from there in a practical matter is a problem.
Adding to the fun is the fact that there are customers that have to use the code and don't care how brilliant the design is. They want something that works today. So there has been a lot of work put in on the Opteron side lately just to make things work. Which painfully lengthens the amount of time disconnects in the design exist.
Eric