Date: Sun, 23 Dec 2007 18:59:49 GMT From: Maxim Zhuravlev <thioretic@FreeBSD.org> To: Perforce Change Reviews <perforce@FreeBSD.org> Subject: PERFORCE change 131484 for review Message-ID: <200712231859.lBNIxnF5068993@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=131484 Change 131484 by thioretic@thioretic on 2007/12/23 18:59:25 Some TODO notes Affected files ... .. //depot/projects/soc2007/thioretic_gidl2/TODO#2 edit Differences ... ==== //depot/projects/soc2007/thioretic_gidl2/TODO#2 (text+ko) ==== @@ -166,4 +166,24 @@ # value returned to a caller. # func - the method from bus_if or driver_if being applied to drivers # memb - the object from driverinfo, which contains the method - # implementation.+ # implementation. +GENERIC NOTES SECTION +--------------------- +TODO: +* Let filter drivers to create iors, that are to be processed by a parent(child) + device, without being processed by other drivers in current device's stack. + Ex. syscons. It includes some private implemented functions from tty interface + and some functions that just call a generic tty functions. + This can be implemented in several ways: + 1) Some kinda *virtual* inheritance of tty driver kobj. + 2) Some library of tty helper functions. + 3) Stacking of syscons driver over generic tty driver. + As for the first way it's a more generic way, but then we won't be able to implement + functions that mix own code and call(s) to generic functions. + As for the second way tty helper functions need some way to know about attached + devices. + As for the third - the optional ior stack propagation is required. +* Trigger infrastructure. A parent(child device) must be able to set a trigger on + its child(parent) state modification (attached, detached...). The trigger events + should be queued so that drivers added to stack later can receive events + for triggers they set.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712231859.lBNIxnF5068993>