On 08/27/2012 11:36 PM, Jiri Svoboda 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.
Then perhaps the driver could return ENXIO or something to that effect when it learns the battery is dead. My concern was that this should not be done by the date command because there may be time sources without batteries or time sources powered by a diesel aggregate. We don't want to be testing for fuel level in the date command, or do we? >> 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). Ok, thanks for taking the time to explain this in detail. At least I have learnt something about our device drivers model :-) Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
