not allow arbitrary memory read/write to physical addresses
So if you want to add a security check to those buffers, the check has to be
inside the kernel. Only the kernel can be trusted, not the userspace
application
that talks to the DRM API
ensource-able
driver, you can too. But without both? Very difficult.
Both VIA and myself have a good relation to Greg K-H from the linux
driver project. But how would we dare to ask somebody to help at a
seemingly impossible task?
--
- Harald Welte htt
r the DRM verification.
So the best we can hope for is that this release will happen soon. After
that 2D Xorg driver has been publicly released, we can ask the DRI developers
to check if the amount of DRI API use in that driver is sufficient for their
requirements.
--
- Harald Welte
I'm just providing my advice to VIA. And that advice clearly is to spend
those few R&D resources they have on proper FOSS drivers for upcoming products,
rather on Chrome9 - which would then mean that we are stuck in the loop where
products are released without a proper FOSS driver, and we k
On Fri, Jul 17, 2009 at 07:09:06PM +1000, Dave Airlie wrote:
> On Fri, Jul 17, 2009 at 4:36 PM, wrote:
> > To whom it may ceoncern:
> > The following 3 patches are the DRM kernel module that support VIA
> > Chorme9 GFX chipset. They are based on 2.6.31-rc3. Please kindly help to
> > integrate
Hi Dave,
thanks for your review.
On Fri, Jul 17, 2009 at 07:08:33PM +1000, Dave Airlie wrote:
> > 1. via_chrome9_3d_reg.h
> > 2. via_chrome9_dma.h
> > 3. via_chrome9_drm.h
> > 4. via_chrome9_drv.h
> > 5. via_chrome9_mm.h
> > 6. via_chrome9_verifier.h
>
> Is it possible to run a 64-bit Linux on a
d description what exactly the change
does, i.e. _how_ the patch fixes the issue you describe.
Thanks for your support,
--
- Harald Welte http://linux.via.com.tw/
===
