Lines Matching full:your

46    conversion or worse, fiddle the raw __u64 through your code since that
60  * Have a clear way for userspace to figure out whether your new ioctl or ioctl
73    and reject the ioctl if that's not the case. Otherwise your nice plan for
99  * Have simple testcases for every input validation failure case in your ioctl.
100    Check that the error code matches your expectations. And finally make sure
106  * Make all your ioctls restartable. First X really loves signals and second
108    interrupting your main test suite constantly with signals. Thanks to X's
109    love for signal you'll get an excellent base coverage of all your error
117    killable. GPUs just die and your users won't like you more if you hang their
122  * Have testcases for the really tricky corner cases in your error recovery code
123    - it's way too easy to create a deadlock between your hangcheck code and
135  * Use CLOCK_MONOTONIC as your reference time, always. It's what alsa, drm and
137    derived from different clock domains like your main system clock (provided
140    have this information they can at least compensate. If your userspace can
151  * For timeouts, use absolute times. If you're a good fellow and made your
153    indefinitely extend your wait time due to rounding on each restart.
154    Especially if your reference clock is something really slow like the display
165    and suiting to your needs.
176  * Always attach the lifetime of your dynamically created resources to the
177    lifetime of a file descriptor. Consider using a 1:1 mapping if your resource
197    of objects, but consider using inode numbers on your shared file descriptors
217    maybe only your testsuite needs this interface, and then debugfs with its
221 your driver proves popular and your hardware platforms long-lived then you'll
223 horrible ioctls on newer iterations of your hardware, but generally it takes