[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cdi-devel] CDI status
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:
> 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.
I'm not certain if end of february would be a good goal here - that's just
a bit to soon, in my opinion. But getting a stable release out soon should
be a primary goal.
> * 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?
I think this should really be done before a release - especially Hotplugging
would be great to have, considering USB.
> * 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.
There's really no need to _change_ the whole interface to add support for
this. Just add functions for asynchronous access, the old synchronous ones
could then be implemented on top of those (ok, doing this at driver level
really cannot to be considered a nice solution, but I think it's acceptable
for a time at least).
> * Logging functions: No concrete suggestions yet
I didn't even know logging functions had come up in discussion ;)
Never heard of those ideas, either. I wouldn't consider this important.
> * 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.
Would definitive be nice to have. If it's doable in a reasonable amount of
time, implement it. Otherwise, really shouldn't be a show stopper.
> * 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.
Totally agree.
> * 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.
Sorry for the lack of activity. I've got a working "prototype" in development,
which _should_ be suitable for most 2d-accelerated applications. But making it
a necessarity is definitive out of question - testing needs to be done, there
are neither drivers working on real hardware atm (don't ask me why the VBE
modeset fails on my hardware, I've got no idea), nor drivers for real hardware
(only software rendering - which is quite slow) . On top of that, video
requires a lot of code on the OS side (for interface and the like). So, let's
just keep this out of the release for now.
> * 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
:)
I could try to get the 3c90x working, or at least help testing (3c905c).
But I've really no idea if I'm going to have the time to do that until end of
February - pre-exams for my Abitur are just around the corner ;)
> * 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.
I'm not quite sure, but as far as I understand it, this is going to have to
wait until the driver loading stuff is done (hardware probing _is_ moving,
isn't it?) - so there's no point in writing tutorials now.
For the small piece of useful hardware, how about using the 3c90x?
Since that driver need's to be done anyway, I'd consider writing about that
development pretty straightforward.
Alex