Messages in this thread |  | | Subject | Re: [RFC] New Driver Model for 2.5 | Date | Fri, 26 Oct 2001 00:53:15 +0100 (BST) | From | Alan Cox <> |
| |
> The cdrecord case is a high level issue, and scsi is a mess ;)
Grin
> We are not yet at a point where we can be more constructive > than what was already said. Ultimately we need to move a bit > forward with the real implementation and see how some problems > show up. The architecture as it was designed so far is light, > and most of the debate is not around it, it's around how it > should be used by drivers & kernel subsystems ;)
I think I understand how to handle this and avoid races. Linus idea of /proc files so you can ask "what is busy" solves most of it. Then the policy daemon can make a choice about suspending or not.
If we make the proc file a large bitmask of events then the policy daemon call to kernel becomes
"suspend even if [event-mask] set"
This means that a daemon call that races the start of say a CD burn will fail and the daemon can rescan, rethink and if need be reissue the request sanely.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |