[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[cdi-devel] CDI status
Hi all,
I'm under impression that we have accumulated so many points that need
work that it's easy to lose the big picture. What I'm trying with this
mail is to summarize them, gather their current status and maybe
throughout this thread turn some abstract things into concrete items
that can be hacked on.
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.
For the other part, I'll just write down the items that I have in mind.
Feel free to add any items I missed. Also, if you want to take an item
maybe you could tell us what your plans looks like. I hope for each item
there is someone who feels responsible - if not, there's something
wrong. And of course you may correct my estimations of the status and/or
importance of a feature.
* 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.
* Automatic Driver Loader: Agreement on the mechanism, patches are
still missing. Important for the release.
* 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.
* Asynchronous interfaces for block and network: No decision yet. We
need a decision for the release as this changes existing interfaces
heavily.
* Logging functions: No concrete suggestions yet
* 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.
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?
* Audio support: Lacks a good interface, implementation blocked by IDC.
I'd consider it optional for the release.
* Video support: Not much aoctivity recently. Optional.
* Network drivers: 3c90x, tulip yet to implement. Making pcnet and e1000
usable on real hardware wouldn't be bad either.
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.
I'm curious what you think about all this.
Kevin