Re: [cdi-devel] CDI status

[Matthew Iselin <matthew@xxxxxxxxxxxxxx>]

On Wed, Feb 3, 2010 at 7:37 AM, Kevin Wolf <kevin@xxxxxxxxxx> wrote:
> First of all, we should decide what the first release of CDI should look
> like - in terms of work done and also regarding the release date. Two or
> three weeks ago I had a conversation with Matt about this and we thought
> that end of February would be a reasonable goal. However, since then
> we've had only little activity, so if we want it to happen, we'll need
> to start moving really soon.

Completely agree.

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

> * 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?

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

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

> * Logging functions: No concrete suggestions yet

I didn't even know logging functions had come up in discussion ;)

> * USB support: Drivers exist for UHCI, OHCI and USB mass storage. They
>  are missing CDI infrastructure (IDC) to work in a clean way. Might
>  need a rewrite or major refactoring according to Max. I tend to say it
>  would be nice to have, but not a show stopper.

Depends on IDC, so we'll see where we get to here.

>  What is Pedigree's policy regarding USB? Only native drivers? Or maybe
>  Max and Eddy could get together and create a nice design that would
>  replace existing drivers?

I don't really mind. Perhaps Max should join #pedigree on Freenode and
have a chat to Eduard about combining forces to develop UHCI, OHCI and
EHCI CDI drivers. I know Eduard has implemented a HID driver, to an
extent, for Pedigree - maybe this could help too?

> * Audio support: Lacks a good interface, implementation blocked by IDC.
>  I'd consider it optional for the release.

Optional - nice to have, but if it's still not around at release time,
forget about it for now.

> * Video support: Not much aoctivity recently. Optional.

I think video needs some serious design discussion before it comes
close to being ready for implementation. I wouldn't be surprised if it
isn't included in the release.

> * 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
:)

> It's a nice list for only four weekends, so I'm not sure how much of it
> we can really do. Probably I also forgot some items that should be
> considered.

Of those that you did....

> * Translate existing headers

Rich seems to be doing a good job with this so far. I'd contribute but
I'd be using Google Translator ;)

> * Write an overview with general information for each module

Sounds like fun. Which modules still need this done?

> * Write some kind of tutorials for driver implementers and CDI
>  implementers

We need to find a small piece of useful hardware that's easy to
program for that we can pick apart and write a tutorial for. That way
the tutorial is practical and has a positive outcome as well.

Cheers,

Matt