Hi,
Jakub Wrote:
> Testing the battery status is a nice demo of the rtc-cmos
> driver abilities, but IMHO is a bit out of scope for the date command.
It's not completely off. The point is that if the battery status indicator says
the battery is dead, it's very likely that the clock reading is not correct.
> +static int
> +rtc_open(ddf_fun_t *fun)
> +{
> ...
> + if (rtc->removed)
> + rc = ENXIO;
> + else {
> + rc = EOK;
> + rtc->clients_connected++;
>
> I am not really sure about this one, but is this really needed? I'd
> assume that a sound device driver framework would not allow you to open
> a non-existing device. Likewise, I'd assume that the softstate gets
> destructed on dev_remove().
You are not opening a device, but a function. dev_remove() is called by the
framework to tell the driver the device is going away. It is up to the driver
to remove any associated functions.
The framework is designed so as to impose as little on the driver-driver and
driver-client communication as possible. It does not allow you to connect to a
function that never existed, granted. When you do ddf_fun_offline(), then
*eventually* it won't be possible to connect to that function.
The framework currently pretty much does not manage the communication between
driver and client - you can even handle the connection yourself. Even if you do
use devman's dispatcher device removal and opening of its functions can run
completely in parallel. The framework makes sure that either the ddf_fun_t *
structure (+ the softstate) still exists and the open succeers, or it does not
exist anymore and the open fails. There is by necessity the window where the
driver has torn down the device, but the framework didn't destroy the ddf_fun_t
and an open comes in, so the driver must determine that the device is no longer
valid.
> The last doubt I have is whether the driver
> is not duplicating some work when maintaining the count of connected
> clients.
Again currently each driver should handle this itself as the framework does not
step into driver-client communication. The correct behavior is to fail the
dev_remove() if some clients are connected (unless the force flag is specified
- this feature will be added in the future).
I know that in both cases above it sounds like there is a lot of code to be
duplicated by each driver. Maybe. My reasoning when designing this was:
- there should be no difference [at least from client point of view] between
talking to a driver and talking to a regular service
- therefore DDF should not interfere with the client-driver IPC in any way
- it should not place any policy on it or limit it in any way
Maybe some of this could be factored out into some common place (not
necessarily the DDF) - ideally for use with both drivers and normal services,
but I think we need more experience with this. Once it is implemented in full
strength in a few drivers, we can think about how to convert it to reusable
code...
Regards
-Jiri
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
