| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20070125220631.GB5886@kroah.com> Date: Thu, 25 Jan 2007 14:06:31 -0800 From: Greg KH <greg@...ah.com> To: Dave Airlie <airlied@...il.com> Cc: airlied@...ux.ie, linux-kernel@...r.kernel.org Subject: Re: gpu sharing layer for kernel On Thu, Jan 25, 2007 at 09:39:47AM +1100, Dave Airlie wrote: > >> Why do we want this? > >> > >> Currently the kernel cannot provide both the fb and drm drivers with > >> access to the device model and this means the drm cannot get any > >> suspend/resume callbacks. This layer attempts to fix this problem by > >> adding a bus for the gpu drivers to attach to. Currently a lowlevel > >> binding driver is needed along with optional fb and drm components. > > > >If we were to allow this kind of "sharing" for all PCI devices would > >that work out instead? Or would this layer still be needed? > > Initially this layer wouldn't be needed, but I'd like to add some > awareness to the drivers, so the drm can tell the fb to stop doing > stuff and vice-versa if necessary.... but perhaps that could be done > with a generic layer also.. or via the lowlevel driver I have... Ok, I have no objection to this layer right now, as it solves your problem, and while I would like some time in the future to add such a layer for the PCI devices, it is no where on my todo plate just yet... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists