Re: [cdi-devel] CDI status

[Kevin Wolf <kevin@xxxxxxxxxx>]

On Wed, Feb 03, 2010 at 01:16:05PM +1000, Matthew Iselin wrote:
> On Wed, Feb 3, 2010 at 7:37 AM, Kevin Wolf <kevin@xxxxxxxxxx> wrote:
> > * mem.h: I think the general approach has been agreed on, we just need
> >  to do the details (most important: find a better name for
> >  cdi_mem_quok_area!) I hope to get it done this week, so I can convert
> >  drivers to it on the weekend. Critical for the release.
> 
> cdi_mem_change_buffer_semantics? It's certainly not an easy function
> to name, especially since its behaviour is hard to explain in a few
> words.

change_buffer_semantics sounds like an existing buffer is modified, not
a new instance is returned. Also, what does semantics mean for a buffer?
I'd likely think of the actual data there.

> 
> > * Automatic Driver Loader: Agreement on the mechanism, patches are
> >  still missing. Important for the release.
> 
> I might be able to put together some patches this week. Should I look
> at making this a priority, in order to get this happening relatively
> soon?

It's a central part of infrastructure (even more so if you take the
cdi_provide_device as a part of it), so I'd say yes. Although this
doesn't mean that other parts are much less important.

> > * Inter-Driver Communication (IDC): As I understand it, this blocks USB
> >  and audio. I'd really like to have it in the release, but I'm not sure
> >  if we can do it in time.
> 
> We'll see how we go here. There's nothing that I know of blocking it
> from being implemented, but implementation and testing might take a
> while...

Well, before implementing it I guess we should start with an interface.
;-)

> > * Asynchronous interfaces for block and network: No decision yet. We
> >  need a decision for the release as this changes existing interfaces
> >  heavily.
> 
> I'd like to hear thoughts from Max and Rich with respect to where we
> are at right now with this discussion. This is probably, in my
> opinion, the most important CDI design step so far as it will affect
> the interface significantly (as you said). The last thing we want to
> do is change the interface post-first-release.

Rich? Max?

I'm not really hesitant to change interfaces later on if it turns out to
be helpful. Being able to change interfaces as need arises is one of our
strengths. And this means that a solution as suggested by Alex (leave
old functions around and add new asynchronous ones) doesn't work for me.
If we get a better interface the old one must die.

That said, getting it right in the release should be our goal.

> > * Logging functions: No concrete suggestions yet
> 
> I didn't even know logging functions had come up in discussion ;)

They came up long ago, but my todo list doesn't forget anything. ;-)

> > * Network drivers: 3c90x, tulip yet to implement. Making pcnet and e1000
> >  usable on real hardware wouldn't be bad either.
> 
> Hmm, I can probably port my 3c90x driver to CDI (but I'm really
> time-poor at the moment). Getting pcnet and e1000 working on real
> hardware should be a high priority though. It's hard to justify using
> a driver interface when the drivers don't work outside of an emulator
> :)

Who has an e1000 or a pcnet in real hardware? I know that Toni has an
e1000, so that's probably a job for him. No idea about pcnet.

> > * Write an overview with general information for each module
> 
> Sounds like fun. Which modules still need this done?

Everything but core.

Kevin