Re: root priv and DRM
On 6/20/05, Alan Cox <[EMAIL PROTECTED]> wrote: > On Sad, 2005-06-18 at 16:54, Jon Smirl wrote: > > How about this as a safe first step: > > 1) Remove the general root capability check > > 2) Change the semantics of the root_only field on these calls to mean > > master only. > > 3) Push the root capability check into each of these IOCTL individually. > > 4) Leave a root capability check on the general switch code to per > > device IOCTLs if they are marked master only. > > This sounds like a way to make mistakes. Far better is to make the check > a set of flags where 0/1 happen to keep their meaning > > ie > > #define DRM_NEED_ROOT 1 > #define DRM_NEED_MASTER 2 > > now anything you miss/forget to touch won't go off in your hand so to > speak. I ended up implementing something closer to this model instead of what I suggested. The patch is up a couple of messages in this thread. I made two columns, root and master, instead of using 1/2. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: root priv and DRM
> I very strongly believe that the right model moving forward is for > user-mode to say to the kernel, "I beg of thee. Initialize thyne self." Much of the initialization of chips is complex and messy and not neccessarily good kernel material. SAREA setup I agree seems an obvious kernel thing to do except that we need to figure who decided what size it should be. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: root priv and DRM
On Sad, 2005-06-18 at 16:54, Jon Smirl wrote: > How about this as a safe first step: > 1) Remove the general root capability check > 2) Change the semantics of the root_only field on these calls to mean > master only. > 3) Push the root capability check into each of these IOCTL individually. > 4) Leave a root capability check on the general switch code to per > device IOCTLs if they are marked master only. This sounds like a way to make mistakes. Far better is to make the check a set of flags where 0/1 happen to keep their meaning ie #define DRM_NEED_ROOT 1 #define DRM_NEED_MASTER 2 now anything you miss/forget to touch won't go off in your hand so to speak. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: root priv and DRM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Jackson wrote: > On Friday 17 June 2005 23:18, Ian Romanick wrote: > >>Basically, user-mode should say to the kernel, "Please initialize >>yourself with these tunable parameters." The kernel should then do >>whatever it wants and let user-mode know what it did. > > Actually right after I said that I remembered that drmAddMap is also used to > set up the SAREA. So, maybe it shouldn't die, but I don't think it should > need to do anything besides the DRM_SHM mappings, and those can be done > without needing root. Why can't the kernel do that too? The only reason I didn't move that into the kernel in the MGA driver is that it would have required too much *more* code surgery in the DDX. I very strongly believe that the right model moving forward is for user-mode to say to the kernel, "I beg of thee. Initialize thyne self." Over the years we've had serveral cases where the user / kernel initialization dance has needed to change, and this has resulted in numerous backwards-compatability nightmares. Moving the whole dance into the kernel won't eliminate all of them, but it will certainly reduce them (IMO). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtvO3X1gOwKyEAw8RAiMoAJ9/FatEuR3ObELyHgS6JsYDeBvVywCdHKTK gxhCmJLPX9eI9VOCN4jIhEs= =g0NF -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: root priv and DRM
DRM has the concepts of master and authenticated. In the current code
master is also equated with needing root priv. The patch splits these
two concepts into three (auth, master, root) and makes them separately
controllable.
For example:
[DRM_IOCTL_NR(DRM_IOCTL_ADD_BUFS)] = {drm_addbufs, 1, 1, 1},
needs auth, master, root.
Right now master and root requirements are always set the same. This
new framework lets us check out each call and start removing the root
requirements. The master requirement will always stay as it currently
is.
I always mark the first opener as being master. Just being marked
master doesn't get you the ability to call root priv IOCTLs.
The current DRM code automatically marks all root openers as being
authenticated. I left that in but I am not sure that it should be
there since it will automatically authorize all root users without the
server knowing to track them. I think the intention was just authorize
the first root user.
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
--- a/linux-core/drmP.h
+++ b/linux-core/drmP.h
@@ -278,6 +278,7 @@ typedef int drm_ioctl_t(struct inode *in
typedef struct drm_ioctl_desc {
drm_ioctl_t *func;
int auth_needed;
+ int master_needed;
int root_only;
} drm_ioctl_desc_t;
@@ -373,6 +374,7 @@ typedef struct drm_buf_entry {
/** File private data */
typedef struct drm_file {
int authenticated;
+ int master;
int minor;
pid_t pid;
uid_t uid;
diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
--- a/linux-core/drm_drv.c
+++ b/linux-core/drm_drv.c
@@ -58,67 +58,67 @@ static int drm_version(struct inode *ino
/** Ioctl table */
drm_ioctl_desc_t drm_ioctls[] = {
- [DRM_IOCTL_NR(DRM_IOCTL_VERSION)] = {drm_version, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_GET_UNIQUE)] = {drm_getunique, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_GET_MAGIC)] = {drm_getmagic, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_IRQ_BUSID)] = {drm_irq_by_busid, 0, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_GET_MAP)] = {drm_getmap, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_GET_CLIENT)] = {drm_getclient, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_GET_STATS)] = {drm_getstats, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_SET_VERSION)] = {drm_setversion, 0, 1},
-
- [DRM_IOCTL_NR(DRM_IOCTL_SET_UNIQUE)] = {drm_setunique, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_BLOCK)] = {drm_noop, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_UNBLOCK)] = {drm_noop, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_AUTH_MAGIC)] = {drm_authmagic, 1, 1},
-
- [DRM_IOCTL_NR(DRM_IOCTL_ADD_MAP)] = {drm_addmap_ioctl, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_RM_MAP)] = {drm_rmmap_ioctl, 1, 0},
-
- [DRM_IOCTL_NR(DRM_IOCTL_SET_SAREA_CTX)] = {drm_setsareactx, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_GET_SAREA_CTX)] = {drm_getsareactx, 1, 0},
-
- [DRM_IOCTL_NR(DRM_IOCTL_ADD_CTX)] = {drm_addctx, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_RM_CTX)] = {drm_rmctx, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_MOD_CTX)] = {drm_modctx, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_GET_CTX)] = {drm_getctx, 1, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_SWITCH_CTX)] = {drm_switchctx, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_NEW_CTX)] = {drm_newctx, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_RES_CTX)] = {drm_resctx, 1, 0},
-
- [DRM_IOCTL_NR(DRM_IOCTL_ADD_DRAW)] = {drm_adddraw, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_RM_DRAW)] = {drm_rmdraw, 1, 1},
-
- [DRM_IOCTL_NR(DRM_IOCTL_LOCK)] = {drm_lock, 1, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_UNLOCK)] = {drm_unlock, 1, 0},
-
- [DRM_IOCTL_NR(DRM_IOCTL_FINISH)] = {drm_noop, 1, 0},
-
- [DRM_IOCTL_NR(DRM_IOCTL_ADD_BUFS)] = {drm_addbufs, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_MARK_BUFS)] = {drm_markbufs, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_INFO_BUFS)] = {drm_infobufs, 1, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_MAP_BUFS)] = {drm_mapbufs, 1, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_FREE_BUFS)] = {drm_freebufs, 1, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_VERSION)] = {drm_version, 0, 0, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_GET_UNIQUE)] = {drm_getunique, 0, 0, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_GET_MAGIC)] = {drm_getmagic, 0, 0, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_IRQ_BUSID)] = {drm_irq_by_busid, 0, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_GET_MAP)] = {drm_getmap, 0, 0, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_GET_CLIENT)] = {drm_getclient, 0, 0, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_GET_STATS)] = {drm_getstats, 0, 0, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_SET_VERSION)] = {drm_setversion, 0, 1, 1},
+
+ [DRM_IOCTL_NR(DRM_IOCTL_SET_UNIQUE)] = {drm_setunique, 1, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_BLOCK)] = {drm_noop, 1, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_UNBLOCK)] = {drm_noop, 1, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_AUTH_MAGIC)] = {drm_authmagic, 1, 1, 1},
+
+ [DRM_IOCTL_NR(DRM_IOCTL_ADD_MAP)] = {drm_addmap_ioctl, 1, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_RM_MAP)] = {drm_rmmap_ioctl, 1, 0, 0},
+
+ [DRM_IOCTL_NR(DRM
Re: root priv and DRM
On 6/17/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> These are the ones marked root.
>
> [DRM_IOCTL_NR(DRM_IOCTL_IRQ_BUSID)] = {drm_irq_by_busid, 0, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_SET_VERSION)] = {drm_setversion, 0, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_SET_UNIQUE)] = {drm_setunique, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_BLOCK)] = {drm_noop, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_UNBLOCK)] = {drm_noop, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_AUTH_MAGIC)] = {drm_authmagic, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_ADD_MAP)] = {drm_addmap_ioctl, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_SET_SAREA_CTX)] = {drm_setsareactx, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_ADD_CTX)] = {drm_addctx, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_RM_CTX)] = {drm_rmctx, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_MOD_CTX)] = {drm_modctx, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_SWITCH_CTX)] = {drm_switchctx, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_NEW_CTX)] = {drm_newctx, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_ADD_DRAW)] = {drm_adddraw, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_RM_DRAW)] = {drm_rmdraw, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_ADD_BUFS)] = {drm_addbufs, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_MARK_BUFS)] = {drm_markbufs, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_CONTROL)] = {drm_control, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_AGP_ACQUIRE)] = {drm_agp_acquire_ioctl, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_AGP_RELEASE)] = {drm_agp_release_ioctl, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_AGP_ENABLE)] = {drm_agp_enable_ioctl, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_AGP_ALLOC)] = {drm_agp_alloc, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_AGP_FREE)] = {drm_agp_free, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_AGP_BIND)] = {drm_agp_bind, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_AGP_UNBIND)] = {drm_agp_unbind, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_SG_ALLOC)] = {drm_sg_alloc, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_SG_FREE)] = {drm_sg_free, 1, 1},
How about this as a safe first step:
1) Remove the general root capability check
2) Change the semantics of the root_only field on these calls to mean
master only.
3) Push the root capability check into each of these IOCTL individually.
4) Leave a root capability check on the general switch code to per
device IOCTLs if they are marked master only.
The net effect of this should be no change to the security model.
Next we review each IOCTL one at a time and start removing their
individual root capability checks when we decide it is safe. Doing
this may require adjustments to the code to make it work. The root
check stays in until there is agreement on dri-devel that it is ok to
remove.
After the general DRM driver is good repeat the process for the chip
specific ones.
This process is going to cause some churn in the DRM code as the root
capability checks are pushed into the lower levels and then removed.
Is that ok with everyone? I think removing security checks like these
needs to be done as publically as possible.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: root priv and DRM
On Friday 17 June 2005 23:18, Ian Romanick wrote: > Adam Jackson wrote: > > drmAddMap has to be root-only because it's mapping device memory into > > userspace (can trigger bus-master writes, blah blah, root escalation). I > > think that's the only one that _really_ needs it, and to be honest those > > mappings should get set up from the DRM side anyway and AddMap should > > just die. > > I agree 100%. In fact, most of my recent work to enable DRI on PCI > Matrox cards focused on exactly that. The code in mga_do_dma_bootstrap > (and friends) is a good model (IM-not-so-HO!) for where the other DRMs > should go. Cool, I'll look into that for the imagine driver. > Basically, user-mode should say to the kernel, "Please initialize > yourself with these tunable parameters." The kernel should then do > whatever it wants and let user-mode know what it did. Actually right after I said that I remembered that drmAddMap is also used to set up the SAREA. So, maybe it shouldn't die, but I don't think it should need to do anything besides the DRM_SHM mappings, and those can be done without needing root. - ajax pgp0ewawrIrAa.pgp Description: PGP signature
Re: root priv and DRM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Jackson wrote: > drmAddMap has to be root-only because it's mapping device memory into > userspace (can trigger bus-master writes, blah blah, root escalation). I > think that's the only one that _really_ needs it, and to be honest those > mappings should get set up from the DRM side anyway and AddMap should just > die. I agree 100%. In fact, most of my recent work to enable DRI on PCI Matrox cards focused on exactly that. The code in mga_do_dma_bootstrap (and friends) is a good model (IM-not-so-HO!) for where the other DRMs should go. Basically, user-mode should say to the kernel, "Please initialize yourself with these tunable parameters." The kernel should then do whatever it wants and let user-mode know what it did. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCs5JqX1gOwKyEAw8RAhKjAJkBSErmFwfgBMX2/3AJv1eJ+FQVWQCgltBk S/0UJ5ThmMPV7XXX+QBjXz0= =wny5 -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: root priv and DRM
On Friday 17 June 2005 22:39, Jon Smirl wrote: > I'm working on making EGL run non-root. Now I'm up against the IOCTLs > in DRM marked root only. DRM is a master/slave model, so this is > really a list of the master only calls. > > With EGL the first app to open the DRI device is master, and later > openers are slaves. To make EGL work PAM assigns you ownership of the > DRI device so that you can open it. > > Does anyone know if there are reasons why you really have to have root > priv to make any of these calls? drmAddMap has to be root-only because it's mapping device memory into userspace (can trigger bus-master writes, blah blah, root escalation). I think that's the only one that _really_ needs it, and to be honest those mappings should get set up from the DRM side anyway and AddMap should just die. - ajax pgpiDMjgb0g4i.pgp Description: PGP signature
root priv and DRM
I'm working on making EGL run non-root. Now I'm up against the IOCTLs
in DRM marked root only. DRM is a master/slave model, so this is
really a list of the master only calls.
With EGL the first app to open the DRI device is master, and later
openers are slaves. To make EGL work PAM assigns you ownership of the
DRI device so that you can open it.
Does anyone know if there are reasons why you really have to have root
priv to make any of these calls?
Can you help with the converse and tell me which ones you are sure
don't need root priv?
What is the status of the various command verifiers?
If we agree that it is safe I'd like to remove the general
capable(CAP_SYS_ADMIN) check when making DRM IOCTL calls. If some
drivers still need it we can make it a per driver option.
These are the ones marked root.
[DRM_IOCTL_NR(DRM_IOCTL_IRQ_BUSID)] = {drm_irq_by_busid, 0, 1},
[DRM_IOCTL_NR(DRM_IOCTL_SET_VERSION)] = {drm_setversion, 0, 1},
[DRM_IOCTL_NR(DRM_IOCTL_SET_UNIQUE)] = {drm_setunique, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_BLOCK)] = {drm_noop, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_UNBLOCK)] = {drm_noop, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_AUTH_MAGIC)] = {drm_authmagic, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_ADD_MAP)] = {drm_addmap_ioctl, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_SET_SAREA_CTX)] = {drm_setsareactx, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_ADD_CTX)] = {drm_addctx, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_RM_CTX)] = {drm_rmctx, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_MOD_CTX)] = {drm_modctx, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_SWITCH_CTX)] = {drm_switchctx, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_NEW_CTX)] = {drm_newctx, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_ADD_DRAW)] = {drm_adddraw, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_RM_DRAW)] = {drm_rmdraw, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_ADD_BUFS)] = {drm_addbufs, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_MARK_BUFS)] = {drm_markbufs, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_CONTROL)] = {drm_control, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_AGP_ACQUIRE)] = {drm_agp_acquire_ioctl, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_AGP_RELEASE)] = {drm_agp_release_ioctl, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_AGP_ENABLE)] = {drm_agp_enable_ioctl, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_AGP_ALLOC)] = {drm_agp_alloc, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_AGP_FREE)] = {drm_agp_free, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_AGP_BIND)] = {drm_agp_bind, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_AGP_UNBIND)] = {drm_agp_unbind, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_SG_ALLOC)] = {drm_sg_alloc, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_SG_FREE)] = {drm_sg_free, 1, 1},
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
