Date: Tue, 29 Sep 2015 00:43:28 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 201611] [patch] Add devfs_get_cdevpriv_from_file(9) Message-ID: <bug-201611-8-hKnXYNynkY@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-201611-8@https.bugs.freebsd.org/bugzilla/> References: <bug-201611-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201611 --- Comment #8 from Andy Ritger <aritger@nvidia.com> --- (In reply to John Baldwin from comment #7) Thanks, John. Those are all fair points. Looking back at my notes, the reason we originally implemented our API as having user-space, rather than kernel-space, create the file descriptor was that doing it in user-space minimized how much in-kernel API churn we would be exposed to (i.e., concern over the API for allocating an fd within the kernel changing across kernel versions). To be fair, that's much more of a concern on Linux than on FreeBSD. In any case, having the ioctl return an fd for the resource should be workable. On the receiving side, I worry that we may still need the flexibility of an ioctl implementation within the kernel looking up information from a file descriptor. Are you very familiar with the Linux dma-buf interface? There is some documentation on it here: https://www.kernel.org/doc/Documentation/dma-buf-sharing.txt I expect those working on porting DRM from Linux to FreeBSD will eventually need to implement drm-buf on FreeBSD, and some of these same fd translation questions will come up, there. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-201611-8-hKnXYNynkY>