New device layout, including static and dynamic initializers

[Eric W. Biederman]

ollie lho <ollie at 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