Re: Freescale Linux BSP review

Re: Freescale Linux BSP review

[Arnd Bergmann]

On Monday 13 December 2010, Jammy Zhou wrote:
> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>wrote:
> 
> > On 11 December 2010 22:41, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> >
> > * amd-gpu -- a single but huge driver for the GPU. As is normally the
> >>             case with GPU drivers, we can expect long discussions
> >>             before it will get considered for mainline
> >>  4 patches
> >>  98 files changed, 278321 insertions(+), 0 deletions(-)
> >>
> >
> > Just out of curiosity, following the discussion between Dave Airlie
> > and Codeaurora this summer re GPU driver shims.
> >
> > Is the AMD GPU exposing all functionality in its kernel driver or
> > is there some userspace blob somewhere with lots of e.g. GL
> > goodies?
> > 
> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
> belongs to Qualcom) is exposed. But we need accompanied userspace library to
> call these functionality (buffer management, command submission, ...).

Who owns these components? If it's closed source, the only options we
have are lobbying for complete release of the specs for a reimplementation
or reverse-engineering the drivers, which may at least get easier with
a user space driver than it would be with a kernel driver.

Until there is a solution with an open source user space part, I would
suggest that the driver better be dropped from the Freescale BSP and
we should at least not waste time reviewing it.

	Arnd

Re: Freescale Linux BSP review

[Jerome Glisse]

On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 13 December 2010, Jammy Zhou wrote:
>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij <linus.walleij@linaro.org>wrote:
>>
>> > On 11 December 2010 22:41, Arnd Bergmann <arnd@arndb.de> wrote:
>> >
>> > * amd-gpu -- a single but huge driver for the GPU. As is normally the
>> >>             case with GPU drivers, we can expect long discussions
>> >>             before it will get considered for mainline
>> >>  4 patches
>> >>  98 files changed, 278321 insertions(+), 0 deletions(-)
>> >>
>> >
>> > Just out of curiosity, following the discussion between Dave Airlie
>> > and Codeaurora this summer re GPU driver shims.
>> >
>> > Is the AMD GPU exposing all functionality in its kernel driver or
>> > is there some userspace blob somewhere with lots of e.g. GL
>> > goodies?
>> >
>> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
>> belongs to Qualcom) is exposed. But we need accompanied userspace library to
>> call these functionality (buffer management, command submission, ...).
>
> Who owns these components? If it's closed source, the only options we
> have are lobbying for complete release of the specs for a reimplementation
> or reverse-engineering the drivers, which may at least get easier with
> a user space driver than it would be with a kernel driver.
>
> Until there is a solution with an open source user space part, I would
> suggest that the driver better be dropped from the Freescale BSP and
> we should at least not waste time reviewing it.
>
>        Arnd

>From a quick look it also seems that the API exposed to userspace
would allow easy abuse of the GPU to access any system ram. There is a
reason we do expensive command checking in the other amd gpu driver
(drivers/gpu/drm/radeon/*cs.c files)

Cheers,
Jerome

Re: Freescale Linux BSP review

[Jammy Zhou]

[-- Attachment #1.1: Type: text/plain, Size: 2214 bytes --]

On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse <j.glisse-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> > On Monday 13 December 2010, Jammy Zhou wrote:
> >> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij <
> linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>wrote:
> >>
> >> > On 11 December 2010 22:41, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> >> >
> >> > * amd-gpu -- a single but huge driver for the GPU. As is normally the
> >> >>             case with GPU drivers, we can expect long discussions
> >> >>             before it will get considered for mainline
> >> >>  4 patches
> >> >>  98 files changed, 278321 insertions(+), 0 deletions(-)
> >> >>
> >> >
> >> > Just out of curiosity, following the discussion between Dave Airlie
> >> > and Codeaurora this summer re GPU driver shims.
> >> >
> >> > Is the AMD GPU exposing all functionality in its kernel driver or
> >> > is there some userspace blob somewhere with lots of e.g. GL
> >> > goodies?
> >> >
> >> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
> >> belongs to Qualcom) is exposed. But we need accompanied userspace
> library to
> >> call these functionality (buffer management, command submission, ...).
> >
> > Who owns these components? If it's closed source, the only options we
> > have are lobbying for complete release of the specs for a
> reimplementation
> > or reverse-engineering the drivers, which may at least get easier with
> > a user space driver than it would be with a kernel driver.
> >
> > Until there is a solution with an open source user space part, I would
> > suggest that the driver better be dropped from the Freescale BSP and
> > we should at least not waste time reviewing it.
> >
> >        Arnd
>
> From a quick look it also seems that the API exposed to userspace
> would allow easy abuse of the GPU to access any system ram. There is a
> reason we do expensive command checking in the other amd gpu driver
> (drivers/gpu/drm/radeon/*cs.c files)
>

No, the memory used by the GPU is reserved at boot time, so I think there is
no such a problem.


>
> Cheers,
> Jerome
>

[-- Attachment #1.2: Type: text/html, Size: 3256 bytes --]

[-- Attachment #2: Type: text/plain, Size: 175 bytes --]

_______________________________________________
linaro-dev mailing list
linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Freescale Linux BSP review

[Jerome Glisse]

On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou <jammy.zhou@linaro.org> wrote:
>
>
> On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
>>
>> On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Monday 13 December 2010, Jammy Zhou wrote:
>> >> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij
>> >> <linus.walleij@linaro.org>wrote:
>> >>
>> >> > On 11 December 2010 22:41, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> >
>> >> > * amd-gpu -- a single but huge driver for the GPU. As is normally the
>> >> >>             case with GPU drivers, we can expect long discussions
>> >> >>             before it will get considered for mainline
>> >> >>  4 patches
>> >> >>  98 files changed, 278321 insertions(+), 0 deletions(-)
>> >> >>
>> >> >
>> >> > Just out of curiosity, following the discussion between Dave Airlie
>> >> > and Codeaurora this summer re GPU driver shims.
>> >> >
>> >> > Is the AMD GPU exposing all functionality in its kernel driver or
>> >> > is there some userspace blob somewhere with lots of e.g. GL
>> >> > goodies?
>> >> >
>> >> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
>> >> belongs to Qualcom) is exposed. But we need accompanied userspace
>> >> library to
>> >> call these functionality (buffer management, command submission, ...).
>> >
>> > Who owns these components? If it's closed source, the only options we
>> > have are lobbying for complete release of the specs for a
>> > reimplementation
>> > or reverse-engineering the drivers, which may at least get easier with
>> > a user space driver than it would be with a kernel driver.
>> >
>> > Until there is a solution with an open source user space part, I would
>> > suggest that the driver better be dropped from the Freescale BSP and
>> > we should at least not waste time reviewing it.
>> >
>> >        Arnd
>>
>> From a quick look it also seems that the API exposed to userspace
>> would allow easy abuse of the GPU to access any system ram. There is a
>> reason we do expensive command checking in the other amd gpu driver
>> (drivers/gpu/drm/radeon/*cs.c files)
>
> No, the memory used by the GPU is reserved at boot time, so I think there is
> no such a problem.
>
>>
>> Cheers,
>> Jerome
>
>

This isn't about what's reserved, this is about GPU capacity, if the
GPU is isolated through an IOMMU and the GPU can't reprogram it then
fine. But if not, then it's easy to abuse packet to reprogram the GPU
GART (either by reprogramming GART register or by overwritting GART
table) to point to any system ram.

Cheers,
Jerome

Re: Freescale Linux BSP review

[Jammy Zhou]

[-- Attachment #1.1: Type: text/plain, Size: 3092 bytes --]

On Tue, Dec 14, 2010 at 10:06 AM, Jerome Glisse <j.glisse-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou <jammy.zhou-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> >
> >
> > On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse <j.glisse-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> wrote:
> >>
> >> On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> >> > On Monday 13 December 2010, Jammy Zhou wrote:
> >> >> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij
> >> >> <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>wrote:
> >> >>
> >> >> > On 11 December 2010 22:41, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> >> >> >
> >> >> > * amd-gpu -- a single but huge driver for the GPU. As is normally
> the
> >> >> >>             case with GPU drivers, we can expect long discussions
> >> >> >>             before it will get considered for mainline
> >> >> >>  4 patches
> >> >> >>  98 files changed, 278321 insertions(+), 0 deletions(-)
> >> >> >>
> >> >> >
> >> >> > Just out of curiosity, following the discussion between Dave Airlie
> >> >> > and Codeaurora this summer re GPU driver shims.
> >> >> >
> >> >> > Is the AMD GPU exposing all functionality in its kernel driver or
> >> >> > is there some userspace blob somewhere with lots of e.g. GL
> >> >> > goodies?
> >> >> >
> >> >> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
> >> >> belongs to Qualcom) is exposed. But we need accompanied userspace
> >> >> library to
> >> >> call these functionality (buffer management, command submission,
> ...).
> >> >
> >> > Who owns these components? If it's closed source, the only options we
> >> > have are lobbying for complete release of the specs for a
> >> > reimplementation
> >> > or reverse-engineering the drivers, which may at least get easier with
> >> > a user space driver than it would be with a kernel driver.
> >> >
> >> > Until there is a solution with an open source user space part, I would
> >> > suggest that the driver better be dropped from the Freescale BSP and
> >> > we should at least not waste time reviewing it.
> >> >
> >> >        Arnd
> >>
> >> From a quick look it also seems that the API exposed to userspace
> >> would allow easy abuse of the GPU to access any system ram. There is a
> >> reason we do expensive command checking in the other amd gpu driver
> >> (drivers/gpu/drm/radeon/*cs.c files)
> >
> > No, the memory used by the GPU is reserved at boot time, so I think there
> is
> > no such a problem.
> >
> >>
> >> Cheers,
> >> Jerome
> >
> >
>
> This isn't about what's reserved, this is about GPU capacity, if the
> GPU is isolated through an IOMMU and the GPU can't reprogram it then
> fine. But if not, then it's easy to abuse packet to reprogram the GPU
> GART (either by reprogramming GART register or by overwritting GART
> table) to point to any system ram.
>

For non-PCI GPU in embedded world, there is no GART concept. Besides, the
GPU MMU is disabled currently for some hardware problem.


>
> Cheers,
> Jerome
>

[-- Attachment #1.2: Type: text/html, Size: 4691 bytes --]

[-- Attachment #2: Type: text/plain, Size: 175 bytes --]

_______________________________________________
linaro-dev mailing list
linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Freescale Linux BSP review

[Jerome Glisse]

On Mon, Dec 13, 2010 at 9:30 PM, Jammy Zhou <jammy.zhou@linaro.org> wrote:
>
>
> On Tue, Dec 14, 2010 at 10:06 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
>>
>> On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou <jammy.zhou@linaro.org> wrote:
>> >
>> >
>> > On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse <j.glisse@gmail.com>
>> > wrote:
>> >>
>> >> On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> > On Monday 13 December 2010, Jammy Zhou wrote:
>> >> >> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij
>> >> >> <linus.walleij@linaro.org>wrote:
>> >> >>
>> >> >> > On 11 December 2010 22:41, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> >> >
>> >> >> > * amd-gpu -- a single but huge driver for the GPU. As is normally
>> >> >> > the
>> >> >> >>             case with GPU drivers, we can expect long discussions
>> >> >> >>             before it will get considered for mainline
>> >> >> >>  4 patches
>> >> >> >>  98 files changed, 278321 insertions(+), 0 deletions(-)
>> >> >> >>
>> >> >> >
>> >> >> > Just out of curiosity, following the discussion between Dave
>> >> >> > Airlie
>> >> >> > and Codeaurora this summer re GPU driver shims.
>> >> >> >
>> >> >> > Is the AMD GPU exposing all functionality in its kernel driver or
>> >> >> > is there some userspace blob somewhere with lots of e.g. GL
>> >> >> > goodies?
>> >> >> >
>> >> >> All the functionality for the kernel driver of AMD GPU Z430/Z160
>> >> >> (now
>> >> >> belongs to Qualcom) is exposed. But we need accompanied userspace
>> >> >> library to
>> >> >> call these functionality (buffer management, command submission,
>> >> >> ...).
>> >> >
>> >> > Who owns these components? If it's closed source, the only options we
>> >> > have are lobbying for complete release of the specs for a
>> >> > reimplementation
>> >> > or reverse-engineering the drivers, which may at least get easier
>> >> > with
>> >> > a user space driver than it would be with a kernel driver.
>> >> >
>> >> > Until there is a solution with an open source user space part, I
>> >> > would
>> >> > suggest that the driver better be dropped from the Freescale BSP and
>> >> > we should at least not waste time reviewing it.
>> >> >
>> >> >        Arnd
>> >>
>> >> From a quick look it also seems that the API exposed to userspace
>> >> would allow easy abuse of the GPU to access any system ram. There is a
>> >> reason we do expensive command checking in the other amd gpu driver
>> >> (drivers/gpu/drm/radeon/*cs.c files)
>> >
>> > No, the memory used by the GPU is reserved at boot time, so I think
>> > there is
>> > no such a problem.
>> >
>> >>
>> >> Cheers,
>> >> Jerome
>> >
>> >
>>
>> This isn't about what's reserved, this is about GPU capacity, if the
>> GPU is isolated through an IOMMU and the GPU can't reprogram it then
>> fine. But if not, then it's easy to abuse packet to reprogram the GPU
>> GART (either by reprogramming GART register or by overwritting GART
>> table) to point to any system ram.
>
> For non-PCI GPU in embedded world, there is no GART concept. Besides, the
> GPU MMU is disabled currently for some hardware problem.
>

In a weird way you lucky ;)

Cheers,
Jerome Glisse

Re: Freescale Linux BSP review

[Dave Airlie]

On Tue, Dec 14, 2010 at 1:18 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 13 December 2010, Jammy Zhou wrote:
>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij <linus.walleij@linaro.org>wrote:
>>
>> > On 11 December 2010 22:41, Arnd Bergmann <arnd@arndb.de> wrote:
>> >
>> > * amd-gpu -- a single but huge driver for the GPU. As is normally the
>> >>             case with GPU drivers, we can expect long discussions
>> >>             before it will get considered for mainline
>> >>  4 patches
>> >>  98 files changed, 278321 insertions(+), 0 deletions(-)
>> >>
>> >
>> > Just out of curiosity, following the discussion between Dave Airlie
>> > and Codeaurora this summer re GPU driver shims.
>> >
>> > Is the AMD GPU exposing all functionality in its kernel driver or
>> > is there some userspace blob somewhere with lots of e.g. GL
>> > goodies?
>> >
>> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
>> belongs to Qualcom) is exposed. But we need accompanied userspace library to
>> call these functionality (buffer management, command submission, ...).
>
> Who owns these components? If it's closed source, the only options we
> have are lobbying for complete release of the specs for a reimplementation
> or reverse-engineering the drivers, which may at least get easier with
> a user space driver than it would be with a kernel driver.

Yeah even with the open kernel bits it makes no sense to upstream if
they never release the userspace,
since a GPU stack is a hw to sw interface stack you can't design a 3D
userspace driver without having
control of the kernel userspace interface, so setting an ABI in stone
for something that forces anyone
doing future development down a strict path is of no benefit.

Dave.

Re: Freescale Linux BSP review

[Jammy Zhou]

[-- Attachment #1.1: Type: text/plain, Size: 2017 bytes --]

On Mon, Dec 13, 2010 at 11:18 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:

> On Monday 13 December 2010, Jammy Zhou wrote:
> > On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
> >wrote:
> >
> > > On 11 December 2010 22:41, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> > >
> > > * amd-gpu -- a single but huge driver for the GPU. As is normally the
> > >>             case with GPU drivers, we can expect long discussions
> > >>             before it will get considered for mainline
> > >>  4 patches
> > >>  98 files changed, 278321 insertions(+), 0 deletions(-)
> > >>
> > >
> > > Just out of curiosity, following the discussion between Dave Airlie
> > > and Codeaurora this summer re GPU driver shims.
> > >
> > > Is the AMD GPU exposing all functionality in its kernel driver or
> > > is there some userspace blob somewhere with lots of e.g. GL
> > > goodies?
> > >
> > All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
> > belongs to Qualcom) is exposed. But we need accompanied userspace library
> to
> > call these functionality (buffer management, command submission, ...).
>
> Who owns these components? If it's closed source, the only options we
> have are lobbying for complete release of the specs for a reimplementation
> or reverse-engineering the drivers, which may at least get easier with
> a user space driver than it would be with a kernel driver.
>

The user space library is closed source, and it is owned by Qualcomm.


>
> Until there is a solution with an open source user space part, I would
> suggest that the driver better be dropped from the Freescale BSP and
> we should at least not waste time reviewing it.
>

I think it is beneficial for us to integrate the kernel part into our Linaro
tree, so that we can build/use it together with the kernel image. As for the
user space libraries, how about adding them into the hwpack? (Is there any
legal issue for this?)


>
>        Arnd
>

[-- Attachment #1.2: Type: text/html, Size: 3007 bytes --]

[-- Attachment #2: Type: text/plain, Size: 175 bytes --]

_______________________________________________
linaro-dev mailing list
linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Freescale Linux BSP review

[Eric Miao]

On Tue, Dec 14, 2010 at 9:59 AM, Jammy Zhou <jammy.zhou@linaro.org> wrote:
>
>
> On Mon, Dec 13, 2010 at 11:18 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Monday 13 December 2010, Jammy Zhou wrote:
>> > On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij
>> > <linus.walleij@linaro.org>wrote:
>> >
>> > > On 11 December 2010 22:41, Arnd Bergmann <arnd@arndb.de> wrote:
>> > >
>> > > * amd-gpu -- a single but huge driver for the GPU. As is normally the
>> > >>             case with GPU drivers, we can expect long discussions
>> > >>             before it will get considered for mainline
>> > >>  4 patches
>> > >>  98 files changed, 278321 insertions(+), 0 deletions(-)
>> > >>
>> > >
>> > > Just out of curiosity, following the discussion between Dave Airlie
>> > > and Codeaurora this summer re GPU driver shims.
>> > >
>> > > Is the AMD GPU exposing all functionality in its kernel driver or
>> > > is there some userspace blob somewhere with lots of e.g. GL
>> > > goodies?
>> > >
>> > All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
>> > belongs to Qualcom) is exposed. But we need accompanied userspace
>> > library to
>> > call these functionality (buffer management, command submission, ...).
>>
>> Who owns these components? If it's closed source, the only options we
>> have are lobbying for complete release of the specs for a reimplementation
>> or reverse-engineering the drivers, which may at least get easier with
>> a user space driver than it would be with a kernel driver.
>
> The user space library is closed source, and it is owned by Qualcomm.
>
>>
>> Until there is a solution with an open source user space part, I would
>> suggest that the driver better be dropped from the Freescale BSP and
>> we should at least not waste time reviewing it.
>
> I think it is beneficial for us to integrate the kernel part into our Linaro
> tree, so that we can build/use it together with the kernel image. As for the
> user space libraries, how about adding them into the hwpack? (Is there any
> legal issue for this?)

I think so, there's normally a rule if free redistribution is allowed
or not, even
it's closed source.

>
>>
>>        Arnd
>
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
>

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Freescale Linux BSP review

[Marcin Juszkiewicz]

Dnia wtorek, 14 grudnia 2010 o 03:35:20 Eric Miao napisał(a):
> > I think it is beneficial for us to integrate the kernel part into our
> > Linaro tree, so that we can build/use it together with the kernel image.
> > As for the user space libraries, how about adding them into the hwpack?
> > (Is there any legal issue for this?)
> 
> I think so, there's normally a rule if free redistribution is allowed
> or not, even it's closed source.

Binary is named libgsl.so and conflicts with GNU Scientific Library package. 
I noticed it ~month ago when played with 2d/3d acceleration for EfikaMX 
Smartbook (i.mx515) and shared that info with Genesi (vendor of netbook). They 
sent that information to Freescale so library will be renamed.

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Freescale Linux BSP review

[Arnd Bergmann]

On Tuesday 14 December 2010, Eric Miao wrote:
> >>
> >> Until there is a solution with an open source user space part, I would
> >> suggest that the driver better be dropped from the Freescale BSP and
> >> we should at least not waste time reviewing it.
> >
> > I think it is beneficial for us to integrate the kernel part into our Linaro
> > tree, so that we can build/use it together with the kernel image. As for the
> > user space libraries, how about adding them into the hwpack? (Is there any
> > legal issue for this?)
> 
> I think so, there's normally a rule if free redistribution is allowed
> or not, even it's closed source.

Well, it can be in the hardware pack, I guess, but I don't think we
should even consider including the driver in the Linaro kernel:

The rule is that we only include code that is on an upstream track
(i.e. merged in an -rc or -next release), which this one clearly
is not at the moment, as Dave Airlie has made quite clear.

We could have a git tree containing all the questionable graphics
drivers (amd, sgx, mali) that rely on proprietary user space libraries,
and allow these to be built against the Linaro kernel, but it needs
to be quite clear that this is in not part of our project.

	Arnd

Re: Freescale Linux BSP review

[Matt Sealey]

On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 13 December 2010, Jammy Zhou wrote:
>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij <linus.walleij@linaro.org>wrote:
>>
>> > On 11 December 2010 22:41, Arnd Bergmann <arnd@arndb.de> wrote:
>> >
>> > * amd-gpu -- a single but huge driver for the GPU. As is normally the
>> >>             case with GPU drivers, we can expect long discussions
>> >>             before it will get considered for mainline
>> >>  4 patches
>> >>  98 files changed, 278321 insertions(+), 0 deletions(-)
>> >>
>> >
>> > Just out of curiosity, following the discussion between Dave Airlie
>> > and Codeaurora this summer re GPU driver shims.
>> >
>> > Is the AMD GPU exposing all functionality in its kernel driver or
>> > is there some userspace blob somewhere with lots of e.g. GL
>> > goodies?
>> >
>> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
>> belongs to Qualcom) is exposed. But we need accompanied userspace library to
>> call these functionality (buffer management, command submission, ...).
>
> Who owns these components? If it's closed source, the only options we
> have are lobbying for complete release of the specs for a reimplementation
> or reverse-engineering the drivers, which may at least get easier with
> a user space driver than it would be with a kernel driver.
>
> Until there is a solution with an open source user space part, I would
> suggest that the driver better be dropped from the Freescale BSP and
> we should at least not waste time reviewing it.

The concerns about host memory access via the GPU driver are valid but
unnecessary. The GPU MMU directly intervenes on memory access and can
only modify memory space allocated to the GPU resource - getting data
into this memory requires some extreme manual intervention if not done
by the kernel driver itself; this memory area is set internally by the
platform device resource.. As such (on the i.MX515 at least) the top
64MB of memory reserved for the GPU is the only memory you need to
worry about, and any "corruption" will be limited to invalid API usage
which is also checked with assertions and other protection mechanisms.
Any other "unsecured" memory location such as system RAM cannot be
affected as the GPU MMU will not write or read any other memory than
the defined resource. It is not an outside possibility that you may
abuse the GPU to corrupt graphics RAM... but you can do that with any
GPU even with security checks.

Ownership of the code is dependent on who licensed it. I do not think
Linaro need be so concerned over opensourcing or reimplementing
drivers. The fact that the kernel driver is open source as it is, and
this is by far the most important part. The userspace library is
closed because it is proprietary; and I think it is well outside
Linaro's remit to lobby for opensourcing of proprietary code simply to
meet an esoteric and needless demand for source code access (as it
stands, you can get source code access by signing the usual plethora
of NDAs with the appropriate vendor, as Genesi has done). It is my
understanding that Freescale/AMD and Qualcomm maintain seperate forks
of the driver and do not cooperate on development, and in any case,
Linaro does not include Qualcomm anyway, therefore it is also to my
understanding that this discussion is also beyond Linaro's remit.

Can't we all just be happy that we actually have 3D drivers?

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Freescale Linux BSP review

[Jerome Glisse]

On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> wrote:
> On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>> On Monday 13 December 2010, Jammy Zhou wrote:
>>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij <linus.walleij-QSEj5FYQhm5QFI55V6+gNQ@public.gmane.orgg>wrote:
>>>
>>> > On 11 December 2010 22:41, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>>> >
>>> > * amd-gpu -- a single but huge driver for the GPU. As is normally the
>>> >>             case with GPU drivers, we can expect long discussions
>>> >>             before it will get considered for mainline
>>> >>  4 patches
>>> >>  98 files changed, 278321 insertions(+), 0 deletions(-)
>>> >>
>>> >
>>> > Just out of curiosity, following the discussion between Dave Airlie
>>> > and Codeaurora this summer re GPU driver shims.
>>> >
>>> > Is the AMD GPU exposing all functionality in its kernel driver or
>>> > is there some userspace blob somewhere with lots of e.g. GL
>>> > goodies?
>>> >
>>> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
>>> belongs to Qualcom) is exposed. But we need accompanied userspace library to
>>> call these functionality (buffer management, command submission, ...).
>>
>> Who owns these components? If it's closed source, the only options we
>> have are lobbying for complete release of the specs for a reimplementation
>> or reverse-engineering the drivers, which may at least get easier with
>> a user space driver than it would be with a kernel driver.
>>
>> Until there is a solution with an open source user space part, I would
>> suggest that the driver better be dropped from the Freescale BSP and
>> we should at least not waste time reviewing it.
>
> The concerns about host memory access via the GPU driver are valid but
> unnecessary. The GPU MMU directly intervenes on memory access and can
> only modify memory space allocated to the GPU resource - getting data
> into this memory requires some extreme manual intervention if not done
> by the kernel driver itself; this memory area is set internally by the
> platform device resource.. As such (on the i.MX515 at least) the top
> 64MB of memory reserved for the GPU is the only memory you need to
> worry about, and any "corruption" will be limited to invalid API usage
> which is also checked with assertions and other protection mechanisms.
> Any other "unsecured" memory location such as system RAM cannot be
> affected as the GPU MMU will not write or read any other memory than
> the defined resource. It is not an outside possibility that you may
> abuse the GPU to corrupt graphics RAM... but you can do that with any
> GPU even with security checks.

Security check of radeon GPU are advance enough to even catch and
forbid overwriting other process video memory (this is more or less
true depending on the generation you are looking at).

> Ownership of the code is dependent on who licensed it. I do not think
> Linaro need be so concerned over opensourcing or reimplementing
> drivers. The fact that the kernel driver is open source as it is, and
> this is by far the most important part. The userspace library is
> closed because it is proprietary; and I think it is well outside
> Linaro's remit to lobby for opensourcing of proprietary code simply to
> meet an esoteric and needless demand for source code access (as it
> stands, you can get source code access by signing the usual plethora
> of NDAs with the appropriate vendor, as Genesi has done). It is my
> understanding that Freescale/AMD and Qualcomm maintain seperate forks
> of the driver and do not cooperate on development, and in any case,
> Linaro does not include Qualcomm anyway, therefore it is also to my
> understanding that this discussion is also beyond Linaro's remit.
>
> Can't we all just be happy that we actually have 3D drivers?

So here you are advocating that we should accept any open source code
inside the kernel just because it's open source and we love open
source ? This is not how i understand the linux kernel project, we
should not accept any open source driver that just add new api that we
can't audit, test or understand. From my point of view any driver &
new API should be introduced to support open source userspace. If GPU
manufacturer don't want to open source their stack that's their issue
but they should live with the pain of not having upstream kernel
either. I believe, here i am just reformulating Dave point.

Cheers,
Jerome Glisse

Re: Freescale Linux BSP review

[Matt Sealey]

On Mon, Dec 20, 2010 at 11:17 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
> On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey <matt@genesi-usa.com> wrote:
>> On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Monday 13 December 2010, Jammy Zhou wrote:
>>>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij <linus.walleij@linaro.org>wrote:
>>>>
>>>> > On 11 December 2010 22:41, Arnd Bergmann <arnd@arndb.de> wrote:
>>>> >
>>>> > * amd-gpu -- a single but huge driver for the GPU. As is normally the
>>>> >>             case with GPU drivers, we can expect long discussions
>>>> >>             before it will get considered for mainline
>>>> >>  4 patches
>>>> >>  98 files changed, 278321 insertions(+), 0 deletions(-)
>>>> >>
>>>> >
>>>> > Just out of curiosity, following the discussion between Dave Airlie
>>>> > and Codeaurora this summer re GPU driver shims.
>>>> >
>>>> > Is the AMD GPU exposing all functionality in its kernel driver or
>>>> > is there some userspace blob somewhere with lots of e.g. GL
>>>> > goodies?
>>>> >
>>>> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
>>>> belongs to Qualcom) is exposed. But we need accompanied userspace library to
>>>> call these functionality (buffer management, command submission, ...).
>>>
>>> Who owns these components? If it's closed source, the only options we
>>> have are lobbying for complete release of the specs for a reimplementation
>>> or reverse-engineering the drivers, which may at least get easier with
>>> a user space driver than it would be with a kernel driver.
>>>
>>> Until there is a solution with an open source user space part, I would
>>> suggest that the driver better be dropped from the Freescale BSP and
>>> we should at least not waste time reviewing it.
>>
>> The concerns about host memory access via the GPU driver are valid but
>> unnecessary. The GPU MMU directly intervenes on memory access and can
>> only modify memory space allocated to the GPU resource - getting data
>> into this memory requires some extreme manual intervention if not done
>> by the kernel driver itself; this memory area is set internally by the
>> platform device resource.. As such (on the i.MX515 at least) the top
>> 64MB of memory reserved for the GPU is the only memory you need to
>> worry about, and any "corruption" will be limited to invalid API usage
>> which is also checked with assertions and other protection mechanisms.
>> Any other "unsecured" memory location such as system RAM cannot be
>> affected as the GPU MMU will not write or read any other memory than
>> the defined resource. It is not an outside possibility that you may
>> abuse the GPU to corrupt graphics RAM... but you can do that with any
>> GPU even with security checks.
>
> Security check of radeon GPU are advance enough to even catch and
> forbid overwriting other process video memory (this is more or less
> true depending on the generation you are looking at).
>
>> Ownership of the code is dependent on who licensed it. I do not think
>> Linaro need be so concerned over opensourcing or reimplementing
>> drivers. The fact that the kernel driver is open source as it is, and
>> this is by far the most important part. The userspace library is
>> closed because it is proprietary; and I think it is well outside
>> Linaro's remit to lobby for opensourcing of proprietary code simply to
>> meet an esoteric and needless demand for source code access (as it
>> stands, you can get source code access by signing the usual plethora
>> of NDAs with the appropriate vendor, as Genesi has done). It is my
>> understanding that Freescale/AMD and Qualcomm maintain seperate forks
>> of the driver and do not cooperate on development, and in any case,
>> Linaro does not include Qualcomm anyway, therefore it is also to my
>> understanding that this discussion is also beyond Linaro's remit.
>>
>> Can't we all just be happy that we actually have 3D drivers?
>
> So here you are advocating that we should accept any open source code
> inside the kernel just because it's open source and we love open
> source ? This is not how i understand the linux kernel project, we
> should not accept any open source driver that just add new api that we
> can't audit, test or understand. From my point of view any driver &
> new API should be introduced to support open source userspace. If GPU
> manufacturer don't want to open source their stack that's their issue
> but they should live with the pain of not having upstream kernel
> either. I believe, here i am just reformulating Dave point.

The code may need improvement but that's no reason to run around
saying everything needs to be open sourced, and that the solution is
in fact to reverse engineer the thing rather than accept it as the
current solution. Given how long nouveau and later Radeon card support
has taken in real life, even with full documentation from AMD, I
seriously doubt Linaro are going to be the ones to somehow make the
world change for OpenSource embedded GPU graphics. Linaro doesn't
exist just to spend all their time undermining the status quo for the
sake of it.

I also do not think that it is at all kernel policy to disallow kernel
drivers which do not have opensource userspace components. In fact,
Linus Torvalds begs to differ on this matter. The fact of the matter
is that the driver lives now, Qualcomm have it in their upstream,
Freescale have it in their upstream, Linaro are going to fetch from
that. It doesn't need to go all the way to stable, because people can
compile their own kernels if they want (and Linaro is there provide
the source to do that with the best interoperability with the silicon
vendors' chips as possible).

Well, good luck reverse engineering the GPU in the next 5 years,
because I suspect that is how long it is going to take.

I would love to see someone actually, physically prove that using the
libraries provided by vendors (Freescale's BSP, or from Genesi or so)
and the kernel driver committed, that you CAN actually cause rampant,
unsecured graphical corruption, before a discussion goes around to
those vendors about spending the next 6 months mired in legal work
trying to find all the potential IP sources and seek approval to
publish that code as opensource or perform rewrites. So far I don't
see that, just a "I'm fairly sure" from a trusted person. This is not
peer review, it's pure opinion. Go see how well you can break it,
submit a bug report, the vendors might fix it in the closed source
libraries or publish a kernel driver update to suit your needs.

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Freescale Linux BSP review

[Jerome Glisse]

On Mon, Dec 20, 2010 at 12:41 PM, Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> wrote:
> On Mon, Dec 20, 2010 at 11:17 AM, Jerome Glisse <j.glisse-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> wrote:
>>> On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>>>> On Monday 13 December 2010, Jammy Zhou wrote:
>>>>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij <linus.walleij@linaro.org>wrote:
>>>>>
>>>>> > On 11 December 2010 22:41, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>>>>> >
>>>>> > * amd-gpu -- a single but huge driver for the GPU. As is normally the
>>>>> >>             case with GPU drivers, we can expect long discussions
>>>>> >>             before it will get considered for mainline
>>>>> >>  4 patches
>>>>> >>  98 files changed, 278321 insertions(+), 0 deletions(-)
>>>>> >>
>>>>> >
>>>>> > Just out of curiosity, following the discussion between Dave Airlie
>>>>> > and Codeaurora this summer re GPU driver shims.
>>>>> >
>>>>> > Is the AMD GPU exposing all functionality in its kernel driver or
>>>>> > is there some userspace blob somewhere with lots of e.g. GL
>>>>> > goodies?
>>>>> >
>>>>> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now
>>>>> belongs to Qualcom) is exposed. But we need accompanied userspace library to
>>>>> call these functionality (buffer management, command submission, ...).
>>>>
>>>> Who owns these components? If it's closed source, the only options we
>>>> have are lobbying for complete release of the specs for a reimplementation
>>>> or reverse-engineering the drivers, which may at least get easier with
>>>> a user space driver than it would be with a kernel driver.
>>>>
>>>> Until there is a solution with an open source user space part, I would
>>>> suggest that the driver better be dropped from the Freescale BSP and
>>>> we should at least not waste time reviewing it.
>>>
>>> The concerns about host memory access via the GPU driver are valid but
>>> unnecessary. The GPU MMU directly intervenes on memory access and can
>>> only modify memory space allocated to the GPU resource - getting data
>>> into this memory requires some extreme manual intervention if not done
>>> by the kernel driver itself; this memory area is set internally by the
>>> platform device resource.. As such (on the i.MX515 at least) the top
>>> 64MB of memory reserved for the GPU is the only memory you need to
>>> worry about, and any "corruption" will be limited to invalid API usage
>>> which is also checked with assertions and other protection mechanisms.
>>> Any other "unsecured" memory location such as system RAM cannot be
>>> affected as the GPU MMU will not write or read any other memory than
>>> the defined resource. It is not an outside possibility that you may
>>> abuse the GPU to corrupt graphics RAM... but you can do that with any
>>> GPU even with security checks.
>>
>> Security check of radeon GPU are advance enough to even catch and
>> forbid overwriting other process video memory (this is more or less
>> true depending on the generation you are looking at).
>>
>>> Ownership of the code is dependent on who licensed it. I do not think
>>> Linaro need be so concerned over opensourcing or reimplementing
>>> drivers. The fact that the kernel driver is open source as it is, and
>>> this is by far the most important part. The userspace library is
>>> closed because it is proprietary; and I think it is well outside
>>> Linaro's remit to lobby for opensourcing of proprietary code simply to
>>> meet an esoteric and needless demand for source code access (as it
>>> stands, you can get source code access by signing the usual plethora
>>> of NDAs with the appropriate vendor, as Genesi has done). It is my
>>> understanding that Freescale/AMD and Qualcomm maintain seperate forks
>>> of the driver and do not cooperate on development, and in any case,
>>> Linaro does not include Qualcomm anyway, therefore it is also to my
>>> understanding that this discussion is also beyond Linaro's remit.
>>>
>>> Can't we all just be happy that we actually have 3D drivers?
>>
>> So here you are advocating that we should accept any open source code
>> inside the kernel just because it's open source and we love open
>> source ? This is not how i understand the linux kernel project, we
>> should not accept any open source driver that just add new api that we
>> can't audit, test or understand. From my point of view any driver &
>> new API should be introduced to support open source userspace. If GPU
>> manufacturer don't want to open source their stack that's their issue
>> but they should live with the pain of not having upstream kernel
>> either. I believe, here i am just reformulating Dave point.
>
> The code may need improvement but that's no reason to run around
> saying everything needs to be open sourced, and that the solution is
> in fact to reverse engineer the thing rather than accept it as the
> current solution. Given how long nouveau and later Radeon card support
> has taken in real life, even with full documentation from AMD, I
> seriously doubt Linaro are going to be the ones to somehow make the
> world change for OpenSource embedded GPU graphics. Linaro doesn't
> exist just to spend all their time undermining the status quo for the
> sake of it.
>
> I also do not think that it is at all kernel policy to disallow kernel
> drivers which do not have opensource userspace components. In fact,
> Linus Torvalds begs to differ on this matter. The fact of the matter
> is that the driver lives now, Qualcomm have it in their upstream,
> Freescale have it in their upstream, Linaro are going to fetch from
> that. It doesn't need to go all the way to stable, because people can
> compile their own kernels if they want (and Linaro is there provide
> the source to do that with the best interoperability with the silicon
> vendors' chips as possible).

I was just expressing my opinion on upstream, if i see this driver
showing up on lkml i will reply with a nak and explain why (pretty
much same argument as here). I don't have any authority on linux
kernel but as far as i understand it, it's about reviewing what's gets
in, so i hope my review opinion would matter (what ever the out come
is).

> Well, good luck reverse engineering the GPU in the next 5 years,
> because I suspect that is how long it is going to take.

It's not that hard, it's time consuming and painfull. The time needed
depends on how much people are working on it and how much time those
people have to work on it.

> I would love to see someone actually, physically prove that using the
> libraries provided by vendors (Freescale's BSP, or from Genesi or so)
> and the kernel driver committed, that you CAN actually cause rampant,
> unsecured graphical corruption, before a discussion goes around to
> those vendors about spending the next 6 months mired in legal work
> trying to find all the potential IP sources and seek approval to
> publish that code as opensource or perform rewrites. So far I don't
> see that, just a "I'm fairly sure" from a trusted person. This is not
> peer review, it's pure opinion. Go see how well you can break it,
> submit a bug report, the vendors might fix it in the closed source
> libraries or publish a kernel driver update to suit your needs.
>

The point here is that we can't prove it or be confidant that it's
very unlikely or even impossible without the specifications, so before
we can have any certainty about this we would either need the
specification or reverse engineer it. Note that i haven't even
bothered looking at that driver, i only looked at other qualcom gpu
and voiced my concern on them (i was given reasonable technical answer
on those concern by the way).

For me, no kernel open source driver should be accepted upstream
without open source userspace. So if a company want to push upstream
an open source kernel driver they have to consider either waiting 5
years for reverse engineering (taking your estimation and assuming
some one reverse engineer). Or actually try to look at those IP and
see what they can do. Some GPU company (AMD, Intel) have proven that
you can actually review IP and do open source driver, they likely
won't disclose how much it cost them but it seems they think it's
worth it. I hope others GPU company will starts thinking about that.

Cheers,
Jerome Glisse
Cheers,
Jerome Glisse

Re: Freescale Linux BSP review

[Arnd Bergmann]

On Monday 20 December 2010 19:07:30 Jerome Glisse wrote:
> > I also do not think that it is at all kernel policy to disallow kernel
> > drivers which do not have opensource userspace components. In fact,
> > Linus Torvalds begs to differ on this matter. The fact of the matter
> > is that the driver lives now, Qualcomm have it in their upstream,
> > Freescale have it in their upstream, Linaro are going to fetch from
> > that. It doesn't need to go all the way to stable, because people can
> > compile their own kernels if they want (and Linaro is there provide
> > the source to do that with the best interoperability with the silicon
> > vendors' chips as possible).
> 
> I was just expressing my opinion on upstream, if i see this driver
> showing up on lkml i will reply with a nak and explain why (pretty
> much same argument as here). I don't have any authority on linux
> kernel but as far as i understand it, it's about reviewing what's gets
> in, so i hope my review opinion would matter (what ever the out come
> is).

There is a broad agreement on disallowing new kernel to userspace
interfaces in the upstream kernel unless there is an application
using it that is both open source and considered useful.

I don't think Linaro as a group takes a position or should take
a position on closed source user space at all -- we just don't
need to bother with it because we have enough work to do on free
components. However, we have a policy on kernel code and that is
as I mentioned before that we don't take code unless it's about to
go upstream. In this case, upstream doesn't take the driver, so
Linaro won't either.

	Arnd

Re: Freescale Linux BSP review

[Alan Cox]

> I also do not think that it is at all kernel policy to disallow kernel
> drivers which do not have opensource userspace components. In fact,

Wrong. The PVR graphics (as used by some Intel embedded for example) is
also not in the kernel for the same reason, ditto some sensor and GPS
devices which are useless without a magic proprietary library.

There are lots of reasons for refusing such code

- Legality questions
- Testability
- Security
- Risk of locking us to proprietary interfaces when we can't change the
  user one

and more

Alan

Re: Freescale Linux BSP review

[Dave Airlie]

>
> The concerns about host memory access via the GPU driver are valid but
> unnecessary. The GPU MMU directly intervenes on memory access and can
> only modify memory space allocated to the GPU resource - getting data
> into this memory requires some extreme manual intervention if not done
> by the kernel driver itself; this memory area is set internally by the
> platform device resource.. As such (on the i.MX515 at least) the top
> 64MB of memory reserved for the GPU is the only memory you need to
> worry about, and any "corruption" will be limited to invalid API usage
> which is also checked with assertions and other protection mechanisms.
> Any other "unsecured" memory location such as system RAM cannot be
> affected as the GPU MMU will not write or read any other memory than
> the defined resource. It is not an outside possibility that you may
> abuse the GPU to corrupt graphics RAM... but you can do that with any
> GPU even with security checks.
>
> Ownership of the code is dependent on who licensed it. I do not think
> Linaro need be so concerned over opensourcing or reimplementing
> drivers. The fact that the kernel driver is open source as it is, and
> this is by far the most important part. The userspace library is
> closed because it is proprietary; and I think it is well outside
> Linaro's remit to lobby for opensourcing of proprietary code simply to
> meet an esoteric and needless demand for source code access (as it
> stands, you can get source code access by signing the usual plethora
> of NDAs with the appropriate vendor, as Genesi has done). It is my
> understanding that Freescale/AMD and Qualcomm maintain seperate forks
> of the driver and do not cooperate on development, and in any case,
> Linaro does not include Qualcomm anyway, therefore it is also to my
> understanding that this discussion is also beyond Linaro's remit.
>
> Can't we all just be happy that we actually have 3D drivers?

Can't you just use Windows? why bother with open source at all if you
are willing to give up.

My point which people keep missing is that graphics stacks are a
single entity, that span kernel and userspace, one cannot exist
without the other, and there are interfaces that join them.

I will accept kernel code to initialise chips, set modes, do all that,
I won't accept new ioctl interfaces to userspace that cannot be
validated and have no use other than to serve the closed user blob.
The reason for this is the burden of maintaining the code/interfaces
falls onto the kernel community when we accept code. Now if we can no
longer validate that the interfaces work without running a binary blob
or we cannot change the interfaces without having to lobby some other
entity to change their blob then maintaining that code in the upstream
kernel is pointless.

I have no problem with closed 3D drivers I just want the manufacturers
to understand that if you want to go down that path you get to keep
both halves.

Dave.

Re: Freescale Linux BSP review

[Alan Cox]

> My point which people keep missing is that graphics stacks are a
> single entity, that span kernel and userspace, one cannot exist
> without the other, and there are interfaces that join them.

As a copyright holder on the kernel I'll also remind the people concerned
that the definition of a derivative work is a legal not a technical one
and if the kernel and user space cannot be used except together and one
half depends on GPL elements I hope your lawyers have reviewed it
carefully. I have never given anyone permission to link my GPL kernel
contributions with anything but GPL code, modular or otherwise, except
according to the derivative work rules laid down by the GPL (and indeed
by the boundaries placed on copyright law).

Alan

Re: Freescale Linux BSP review

[Piotr Gluszenia Slawinski]

On Mon, 20 Dec 2010, Alan Cox wrote:

>> My point which people keep missing is that graphics stacks are a
>> single entity, that span kernel and userspace, one cannot exist
>> without the other, and there are interfaces that join them.
>
> As a copyright holder on the kernel I'll also remind the people concerned
> that the definition of a derivative work is a legal not a technical one
> and if the kernel and user space cannot be used except together and one
> half depends on GPL elements I hope your lawyers have reviewed it
> carefully. I have never given anyone permission to link my GPL kernel
> contributions with anything but GPL code, modular or otherwise, except
> according to the derivative work rules laid down by the GPL (and indeed
> by the boundaries placed on copyright law).

but it can be circumvented by writing GPL driver which will act as 'glue 
logic' inbetween userspace driver and which will work in kernel space?

technically then driver would be GPL, except it's closed parts which will 
be ran in userspace... or can you forbid usage of certain closed userspace 
components with kernel?

p.s. let's skip for now discussion who "should" write such driver, as i 
understand anyone can do it anyway.

-- 

Re: Freescale Linux BSP review

[Arnd Bergmann]

On Tuesday 21 December 2010 03:17:40 Piotr Gluszenia Slawinski wrote:
> On Mon, 20 Dec 2010, Alan Cox wrote:
> 
> >> My point which people keep missing is that graphics stacks are a
> >> single entity, that span kernel and userspace, one cannot exist
> >> without the other, and there are interfaces that join them.
> >
> > As a copyright holder on the kernel I'll also remind the people concerned
> > that the definition of a derivative work is a legal not a technical one
> > and if the kernel and user space cannot be used except together and one
> > half depends on GPL elements I hope your lawyers have reviewed it
> > carefully. I have never given anyone permission to link my GPL kernel
> > contributions with anything but GPL code, modular or otherwise, except
> > according to the derivative work rules laid down by the GPL (and indeed
> > by the boundaries placed on copyright law).
> 
> but it can be circumvented by writing GPL driver which will act as 'glue 
> logic' inbetween userspace driver and which will work in kernel space?
> 
> technically then driver would be GPL, except it's closed parts which will 
> be ran in userspace... or can you forbid usage of certain closed userspace 
> components with kernel?

Anyone can try shipping this and risk a lawsuit, and all copyright holders
of the kernel can try suing people that distribute such code. Most sensible
people stay out of both the shipping questionable code and the suing part,
but apparently the entire mobile phone industry is already doing both, so
we can just wait and see if anyone has deep enough pockets to bring this
up in court first ;-).

The only thing that is currently being enforced is that no interfaces enter
the mainline kernel that rely on closed source user space. Once something
is merged in mainline, you are generally free to write code under any
license you want against that interface.

	Arnd

Re: Freescale Linux BSP review

[Matt Sealey]

On Tue, Dec 21, 2010 at 5:50 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Tuesday 21 December 2010 03:17:40 Piotr Gluszenia Slawinski wrote:
>> On Mon, 20 Dec 2010, Alan Cox wrote:
>>
>> >> My point which people keep missing is that graphics stacks are a
>> >> single entity, that span kernel and userspace, one cannot exist
>> >> without the other, and there are interfaces that join them.
>> >
>> > As a copyright holder on the kernel I'll also remind the people concerned
>> > that the definition of a derivative work is a legal not a technical one
>> > and if the kernel and user space cannot be used except together and one
>> > half depends on GPL elements I hope your lawyers have reviewed it
>> > carefully. I have never given anyone permission to link my GPL kernel
>> > contributions with anything but GPL code, modular or otherwise, except
>> > according to the derivative work rules laid down by the GPL (and indeed
>> > by the boundaries placed on copyright law).
>>
>> but it can be circumvented by writing GPL driver which will act as 'glue
>> logic' inbetween userspace driver and which will work in kernel space?
>>
>> technically then driver would be GPL, except it's closed parts which will
>> be ran in userspace... or can you forbid usage of certain closed userspace
>> components with kernel?
>
> Anyone can try shipping this and risk a lawsuit, and all copyright holders
> of the kernel can try suing people that distribute such code. Most sensible
> people stay out of both the shipping questionable code and the suing part,
> but apparently the entire mobile phone industry is already doing both, so
> we can just wait and see if anyone has deep enough pockets to bring this
> up in court first ;-).

Nobody will because it is unenforcable.

The GPLv2 is written such that the "if you're interfacing the kernel
or compiler you don't need to opensource that bit with your app"
clause can actually be manipulated to basically disavow closed source
code from having to be published as open source if it interfaces with
the standard operating system components. It is meant to protect
software developers from having to bundle a gigabyte of kernel and
compiler code with their 100 line app that uses an ioctl, but legally
it works against  the GPL in this way. It is what means AMD, nVidia,
Intel (hi Alan), and others can produce binary code and binary
executables that run on opensource kernels (wireless regulatory daemon
in the early days) basically with impunity.

You may think it's a horrible idea, and from a technical perspective
it is, but from a legal perspective.. it's not a problem.

> The only thing that is currently being enforced is that no interfaces enter
> the mainline kernel that rely on closed source user space. Once something
> is merged in mainline, you are generally free to write code under any
> license you want against that interface.

Yes, this is basically it: the problem here is that Alan is
stipulating that as a copyright holder in the kernel he has a big
problem with merging the code, but in fact as the merge proposal only
includes GPL code, nobody has a leg to stand on except on moral
grounds, and policy grounds. There is no legal issue here. It is not
going into mainline, fair enough. What I am curious about is why did
Linaro push it to dri-devel in the first place? I think the concept of
taking a driver from a BSP and then just FLINGING it at mainline is
not responsible in the first place. Isn't it enough to go into the
Linaro tree, discretely and quietly? Then we can have a discussion
about what to do about it within Linaro.

Frankly, this discussion (besides the sidetrack to the non-existant
legal issues) did pop up a major problem in the possibility of
unifying the IPU, dual GPU and other graphics subsystem frameworks on
the i.MX processor line, and potentially others too (TI's LCDC and PVR
graphics) in that DRM/DRI security policy will forbid them (in the
form of David Arlie complaining) from sharing the same memory area,
MMUs on or off. This actually means all 2D, 2D acceleration, 3D
acceleration and DMA between the units requires bounce buffers and
some overly complicated memory copying between memory areas for them
to interoperate. I think TI hit this problem trying to get a texture
from the DSP to the GPU to render it to a texture and came up with an
awful (closed source :) method of ioctls and so on to achieve it. I
had an idea to solve it using DRM and GEM but it's been shot down in
concept now... what's the point? It'll never get into mainline.

-- 
Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org>
Product Development Analyst, Genesi USA, Inc.

Re: Freescale Linux BSP review

[Arnd Bergmann]

On Tuesday 21 December 2010 18:29:56 Matt Sealey wrote:

> > The only thing that is currently being enforced is that no interfaces enter
> > the mainline kernel that rely on closed source user space. Once something
> > is merged in mainline, you are generally free to write code under any
> > license you want against that interface.
> 
> Yes, this is basically it: the problem here is that Alan is
> stipulating that as a copyright holder in the kernel he has a big
> problem with merging the code, but in fact as the merge proposal only
> includes GPL code, nobody has a leg to stand on except on moral
> grounds, and policy grounds. There is no legal issue here. It is not
> going into mainline, fair enough. What I am curious about is why did
> Linaro push it to dri-devel in the first place? I think the concept of
> taking a driver from a BSP and then just FLINGING it at mainline is
> not responsible in the first place. Isn't it enough to go into the
> Linaro tree, discretely and quietly? Then we can have a discussion
> about what to do about it within Linaro.

That's not how Linaro works. I forwarded it to the DRI list
to get technical input on what would be needed to have it merged
in mainline. If things were looking better on this front, we could
get it on track for mainline merging, and backport it into the Linaro
tree as soon as it hits linux-next. This is obviously not going
to happen unless we can find at least a subset of the code without
legal problems that we can clean up enough for integration.
 
> Frankly, this discussion (besides the sidetrack to the non-existant
> legal issues) did pop up a major problem in the possibility of
> unifying the IPU, dual GPU and other graphics subsystem frameworks on
> the i.MX processor line, and potentially others too (TI's LCDC and PVR
> graphics) in that DRM/DRI security policy will forbid them (in the
> form of David Arlie complaining) from sharing the same memory area,
> MMUs on or off. This actually means all 2D, 2D acceleration, 3D
> acceleration and DMA between the units requires bounce buffers and
> some overly complicated memory copying between memory areas for them
> to interoperate. I think TI hit this problem trying to get a texture
> from the DSP to the GPU to render it to a texture and came up with an
> awful (closed source :) method of ioctls and so on to achieve it. I
> had an idea to solve it using DRM and GEM but it's been shot down in
> concept now... what's the point? It'll never get into mainline.

Don't give up so early, there are a number of separate problems to
solve here. As far as I understand, the desire among many people
is to have the 3D acceleration hidden. Fine, so we can still do
accelerated 2D with free drivers and shouldn't be bothered by the
fact that we don't get 3D. There is a lot of work to do on proper
2D drivers and getting them into mainline still, so let's focus
on that and do a proper implementation for as many chips as possible.

By the time that is done, we may well have one or more manufacturers
willing to work with us on 3D support as well.

	Arnd

Re: Freescale Linux BSP review

[Dave Airlie]

On Wed, Dec 22, 2010 at 3:29 AM, Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> wrote:
> On Tue, Dec 21, 2010 at 5:50 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>> On Tuesday 21 December 2010 03:17:40 Piotr Gluszenia Slawinski wrote:
>>> On Mon, 20 Dec 2010, Alan Cox wrote:
>>>
>>> >> My point which people keep missing is that graphics stacks are a
>>> >> single entity, that span kernel and userspace, one cannot exist
>>> >> without the other, and there are interfaces that join them.
>>> >
>>> > As a copyright holder on the kernel I'll also remind the people concerned
>>> > that the definition of a derivative work is a legal not a technical one
>>> > and if the kernel and user space cannot be used except together and one
>>> > half depends on GPL elements I hope your lawyers have reviewed it
>>> > carefully. I have never given anyone permission to link my GPL kernel
>>> > contributions with anything but GPL code, modular or otherwise, except
>>> > according to the derivative work rules laid down by the GPL (and indeed
>>> > by the boundaries placed on copyright law).
>>>
>>> but it can be circumvented by writing GPL driver which will act as 'glue
>>> logic' inbetween userspace driver and which will work in kernel space?
>>>
>>> technically then driver would be GPL, except it's closed parts which will
>>> be ran in userspace... or can you forbid usage of certain closed userspace
>>> components with kernel?
>>
>> Anyone can try shipping this and risk a lawsuit, and all copyright holders
>> of the kernel can try suing people that distribute such code. Most sensible
>> people stay out of both the shipping questionable code and the suing part,
>> but apparently the entire mobile phone industry is already doing both, so
>> we can just wait and see if anyone has deep enough pockets to bring this
>> up in court first ;-).
>
> Nobody will because it is unenforcable.
>
> The GPLv2 is written such that the "if you're interfacing the kernel
> or compiler you don't need to opensource that bit with your app"
> clause can actually be manipulated to basically disavow closed source
> code from having to be published as open source if it interfaces with
> the standard operating system components. It is meant to protect
> software developers from having to bundle a gigabyte of kernel and
> compiler code with their 100 line app that uses an ioctl, but legally
> it works against  the GPL in this way. It is what means AMD, nVidia,
> Intel (hi Alan), and others can produce binary code and binary
> executables that run on opensource kernels (wireless regulatory daemon
> in the early days) basically with impunity.
>
> You may think it's a horrible idea, and from a technical perspective
> it is, but from a legal perspective.. it's not a problem.

You should probably refrain from stating legal opinions around here,
Alan stated there is a possible issue legally and you should talk to
lawyers. I find his reasoning to be sane but no idea if its legal. The
point you are missing (you seem to not think much before typing) is
this:

you have two pieces of code, a userspace 3D *driver* (not
application), and a kernel driver talking to the hw, if the userspace
3D driver cannot exist without the kernel driver, it could very well
be considered a derivative work of the kernel driver. You are not
protected by the standard Linux system call exception since it states
"normal system calls", so adding a driver to the kernel to expose a
bunch of driver specific ioctls to allow the userspace 3D work blurs
the lines sufficiently that you are into the domain of derived works
and should call your lawyers.


>
> Frankly, this discussion (besides the sidetrack to the non-existant
> legal issues) did pop up a major problem in the possibility of
> unifying the IPU, dual GPU and other graphics subsystem frameworks on
> the i.MX processor line, and potentially others too (TI's LCDC and PVR
> graphics) in that DRM/DRI security policy will forbid them (in the
> form of David Arlie complaining) from sharing the same memory area,
> MMUs on or off. This actually means all 2D, 2D acceleration, 3D
> acceleration and DMA between the units requires bounce buffers and
> some overly complicated memory copying between memory areas for them
> to interoperate. I think TI hit this problem trying to get a texture
> from the DSP to the GPU to render it to a texture and came up with an
> awful (closed source :) method of ioctls and so on to achieve it. I
> had an idea to solve it using DRM and GEM but it's been shot down in
> concept now... what's the point? It'll never get into mainline.

I never said the security policy would forbid anything, I said they
need to prove
that they've thought about these things and can prove they are secure, if this
requires opening the code and/or documents then that is the way it is. The
thing is if you require a userspace application with user privs to
access these devices
then you must stop the user from doing bad things, from my experience vendors
give little concern for these issues until

a) upstream people point out the problem and refuse to merge
b) they are used as the rootkit entry point.

Dave.

Re: Freescale Linux BSP review

[Piotr Gluszenia Slawinski]

> you have two pieces of code, a userspace 3D *driver* (not
> application), and a kernel driver talking to the hw, if the userspace
> 3D driver cannot exist without the kernel driver, it could very well
> be considered a derivative work of the kernel driver. You are not
> protected by the standard Linux system call exception since it states
> "normal system calls", so adding a driver to the kernel to expose a
> bunch of driver specific ioctls to allow the userspace 3D work blurs
> the lines sufficiently that you are into the domain of derived works
> and should call your lawyers.

so any user-written (gpl compatible) driver which exposes new ioctls
which allow other software to work (i.e. network driver allowing closed
source software to send and recieve packets is illegal aswell?

it is getting confusing...

shall everyone hire lawyer prior to using any software under linux?

-- 

Re: Freescale Linux BSP review

[Dave Airlie]

On Wed, Dec 22, 2010 at 11:54 AM, Piotr Gluszenia Slawinski
<curious-APZTmCvJ1e4cvTeJY7g42e4opr6GJZWbqwyb7XGsRfw@public.gmane.org> wrote:
>> you have two pieces of code, a userspace 3D *driver* (not
>> application), and a kernel driver talking to the hw, if the userspace
>> 3D driver cannot exist without the kernel driver, it could very well
>> be considered a derivative work of the kernel driver. You are not
>> protected by the standard Linux system call exception since it states
>> "normal system calls", so adding a driver to the kernel to expose a
>> bunch of driver specific ioctls to allow the userspace 3D work blurs
>> the lines sufficiently that you are into the domain of derived works
>> and should call your lawyers.
>
> so any user-written (gpl compatible) driver which exposes new ioctls
> which allow other software to work (i.e. network driver allowing closed
> source software to send and recieve packets is illegal aswell?
>
> it is getting confusing...

You need to read before replying.

If the interface is a generic interface that any software can use then
its fine, when the interface is a specific interface for a specific
closed userspace driver it becomes questionable.

Again you are thinking general case when we are talking specifics.

>
> shall everyone hire lawyer prior to using any software under linux?
>

this is a peanut gallery comment, nobody mentioned using any software
under linux here, we are talking about development of linux software.

Please read and understand before replying with pointless emails like this.

Dave.

Re: Freescale Linux BSP review

[Piotr Gluszenia Slawinski]

> You need to read before replying.
>
> If the interface is a generic interface that any software can use then
> its fine, when the interface is a specific interface for a specific
> closed userspace driver it becomes questionable.
>
> Again you are thinking general case when we are talking specifics.

thank you for claryfing , and for your time, excuse me my ignorance.

i think main reason of my confusion is lack of clear specification
of the 'specifics'. discussion becomes plainly too complex
and same development goes - code and strategies are developed before
clarification of the specifics, then people try to explain how they
interpreted law, and start to correct themselves, trying to drag the line
to their side.

i think this wastes time of everyone , of which most loud group are 
users, and most opressed - developers, and excuse me i am making humorous 
comments to point that.

i also hope 3d drivers will finally be free, and not require people to use 
tools like hacked ndiswrapper.


-- 

Re: Freescale Linux BSP review

[Matt Sealey]

Okay I hereby refrain from legal comments.

In any case, this code has passed legal at Freescale and AMD *AND*
Qualcomm. It would not be GPL if it has not been vetted (and it took
them a year to get to this point).

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.



On Tue, Dec 21, 2010 at 7:32 PM, Dave Airlie <airlied@gmail.com> wrote:
> On Wed, Dec 22, 2010 at 3:29 AM, Matt Sealey <matt@genesi-usa.com> wrote:
>> On Tue, Dec 21, 2010 at 5:50 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Tuesday 21 December 2010 03:17:40 Piotr Gluszenia Slawinski wrote:
>>>> On Mon, 20 Dec 2010, Alan Cox wrote:
>>>>
>>>> >> My point which people keep missing is that graphics stacks are a
>>>> >> single entity, that span kernel and userspace, one cannot exist
>>>> >> without the other, and there are interfaces that join them.
>>>> >
>>>> > As a copyright holder on the kernel I'll also remind the people concerned
>>>> > that the definition of a derivative work is a legal not a technical one
>>>> > and if the kernel and user space cannot be used except together and one
>>>> > half depends on GPL elements I hope your lawyers have reviewed it
>>>> > carefully. I have never given anyone permission to link my GPL kernel
>>>> > contributions with anything but GPL code, modular or otherwise, except
>>>> > according to the derivative work rules laid down by the GPL (and indeed
>>>> > by the boundaries placed on copyright law).
>>>>
>>>> but it can be circumvented by writing GPL driver which will act as 'glue
>>>> logic' inbetween userspace driver and which will work in kernel space?
>>>>
>>>> technically then driver would be GPL, except it's closed parts which will
>>>> be ran in userspace... or can you forbid usage of certain closed userspace
>>>> components with kernel?
>>>
>>> Anyone can try shipping this and risk a lawsuit, and all copyright holders
>>> of the kernel can try suing people that distribute such code. Most sensible
>>> people stay out of both the shipping questionable code and the suing part,
>>> but apparently the entire mobile phone industry is already doing both, so
>>> we can just wait and see if anyone has deep enough pockets to bring this
>>> up in court first ;-).
>>
>> Nobody will because it is unenforcable.
>>
>> The GPLv2 is written such that the "if you're interfacing the kernel
>> or compiler you don't need to opensource that bit with your app"
>> clause can actually be manipulated to basically disavow closed source
>> code from having to be published as open source if it interfaces with
>> the standard operating system components. It is meant to protect
>> software developers from having to bundle a gigabyte of kernel and
>> compiler code with their 100 line app that uses an ioctl, but legally
>> it works against  the GPL in this way. It is what means AMD, nVidia,
>> Intel (hi Alan), and others can produce binary code and binary
>> executables that run on opensource kernels (wireless regulatory daemon
>> in the early days) basically with impunity.
>>
>> You may think it's a horrible idea, and from a technical perspective
>> it is, but from a legal perspective.. it's not a problem.
>
> You should probably refrain from stating legal opinions around here,
> Alan stated there is a possible issue legally and you should talk to
> lawyers. I find his reasoning to be sane but no idea if its legal. The
> point you are missing (you seem to not think much before typing) is
> this:
>
> you have two pieces of code, a userspace 3D *driver* (not
> application), and a kernel driver talking to the hw, if the userspace
> 3D driver cannot exist without the kernel driver, it could very well
> be considered a derivative work of the kernel driver. You are not
> protected by the standard Linux system call exception since it states
> "normal system calls", so adding a driver to the kernel to expose a
> bunch of driver specific ioctls to allow the userspace 3D work blurs
> the lines sufficiently that you are into the domain of derived works
> and should call your lawyers.
>
>
>>
>> Frankly, this discussion (besides the sidetrack to the non-existant
>> legal issues) did pop up a major problem in the possibility of
>> unifying the IPU, dual GPU and other graphics subsystem frameworks on
>> the i.MX processor line, and potentially others too (TI's LCDC and PVR
>> graphics) in that DRM/DRI security policy will forbid them (in the
>> form of David Arlie complaining) from sharing the same memory area,
>> MMUs on or off. This actually means all 2D, 2D acceleration, 3D
>> acceleration and DMA between the units requires bounce buffers and
>> some overly complicated memory copying between memory areas for them
>> to interoperate. I think TI hit this problem trying to get a texture
>> from the DSP to the GPU to render it to a texture and came up with an
>> awful (closed source :) method of ioctls and so on to achieve it. I
>> had an idea to solve it using DRM and GEM but it's been shot down in
>> concept now... what's the point? It'll never get into mainline.
>
> I never said the security policy would forbid anything, I said they
> need to prove
> that they've thought about these things and can prove they are secure, if this
> requires opening the code and/or documents then that is the way it is. The
> thing is if you require a userspace application with user privs to
> access these devices
> then you must stop the user from doing bad things, from my experience vendors
> give little concern for these issues until
>
> a) upstream people point out the problem and refuse to merge
> b) they are used as the rootkit entry point.
>
> Dave.
>

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Freescale Linux BSP review

[Konstantinos Margaritis]

On 22 December 2010 09:51, Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> wrote:
> Okay I hereby refrain from legal comments.
>
> In any case, this code has passed legal at Freescale and AMD *AND*
> Qualcomm. It would not be GPL if it has not been vetted (and it took
> them a year to get to this point).

It appears that this discussion ended up on phoronix.com [1], with an
air of hostility towards Genesi and Matt for no good reason.

I don't know whose idea was that, but it's certainly of very bad taste
and helps very little to the discussion. Matt poses real questions and
issues we -as a company producing ARM products- face all the time.
Admittedly the technical reasons for not including the kernel-space
driver into mainline presented by Dave Airlie are correct and very
down-to-earth. But IMHO, *this* should be the starting point to
continue the discussion, instead of immediately rejecting this driver.
Is there *any* way that problem posed by Dave could be solved, perhaps
by throwing the ball to the ARM vendor companies to provide just a
small extra part of the code needed to do API checks and therefore
ensuring the kernel guys CAN actually do their work as they like?

As for the philosophical problems, well, I'm sure everyone here
understands that the situation of ARM graphics in the kernel is in no
way comparable to Intel or Nvidia/ATI chipsets, they had totally
different starting points. ARM came from the embedded market where it
thrived for many years with the exact same licensing rules that we all
would like to abolish in just a few months, where at the same time we
"swallowed" the fact that it took Intel and ATI/AMD - forget nvidia,
nv-obfuscated driver IN the kernel for YEARS? really? - many years to
accept mainline opensource development. And even Intel with all their
experience made a complete mess of things using the latest cpus.

I *really* do appreciate Linaro and the effort from ARM and the
relevant vendors towards open source enablement, and Genesi has proven
that by donating ~50 ARM based netbooks and smarttops to Linaro
developers at Linaro@UDS -and around ~40 units to other projects
including Debian and Gentoo -and we intend to give more in the future.
We know the process and how it works, just as well as everyone here
does actually. But we also have to be pragmatic. An ARM based
solution/product with no long-term support from the kernel side will
find it very hard to survive indeed. I strongly believe that, half a
solution is better than no solution, and it can also serve a purpose
until a proper full solution appears. It also does show a leap of good
faith from the FOSS side, and one which ARM companies will have to
follow soon.

So, if by chance anyone really expects ARM licensees to do 180 degrees
change in philosophy overnight, I obviously cannot speak for them, but
IMHO, that is not bound to happen. It will probably happen in a few
years but only by discussion and collaboration, seriously not by
dealing with absolutes. Denying even the smallest step backwards from
the side of the FOSS community is not a victory, it's a downright
failure of the community side to actively support and push ARM -based
devices as an alternative Linux desktop and portable solutions
(netbook etc).

My 2c.

Konstantinos

[1]: http://www.phoronix.com/scan.php?page=news_item&px=ODk0NA

Re: Freescale Linux BSP review

[David Rusling]

Konstantinos,
	thanks, I agree with your thoughts.   My approach has been to accept small steps in the right direction and encourage reasoned discussion.   I also think that Linaro's main function is as a place where all the moving parts can collaborate.    Right now, the GPU 'problem' is that of getting both open source and proprietary pieces of the BSPs to work really well together in products.   That's really the focus of the Graphics WGs and the partner landing teams.   This is a heavy lifting engineering job, and it will take time, but everyone is willing and hopeful of good results.    Doing this will also help us have a reasoned discussion about where the open source and proprietary boundaries make sense.

	Now for a bit of a rant.   Personally, I have a deep and abiding respect for open source (for me, it's the key social invention of the internet age), however I also recognise that it would not exist without companies using open source as part of their products.    Let's face it, an awful lot of open source engineers are getting their mortgages paid by companies that make use of open source.     No company invests in open source for philanthropic reasons; they understand that it is necessary for their businesses.    The tricky problem is always in how ethical a company's usage is (and I use the word 'ethical' deliberately because this is wider than mere legal words smithing); whenever I give talks on GPL, I emphasise both the moral as well as the legal duties.    In my experience, most com
 panies struggle to understand open source when they first start to interact with it.   It usually takes some open source zealots within the company to persuade their management of the right way to behave.   The best way to get companies to change their behaviour is to find them and support them.  Making threatening GPL noises in email does not help them in any way.

Dave


David Rusling, CTO
http://www.linaro.org

Linaro
Lockton House
Clarendon Rd
Cambridge
CB2 8FH

Re: Freescale Linux BSP review

[Nicolas Pitre]

On Wed, 22 Dec 2010, David Rusling wrote:

> 	Now for a bit of a rant.  Personally, I have a deep and abiding 
> respect for open source (for me, it's the key social invention of the 
> internet age), however I also recognise that it would not exist 
> without companies using open source as part of their products.  Let's 
> face it, an awful lot of open source engineers are getting their 
> mortgages paid by companies that make use of open source.

I cannot be in full agreement with the above statement.  I think the 
reality is way more nuanced than that.

The truth of the matter is that Open Source came into existence without 
and despite involvement from the corporate world.  And the very reason 
it started to attract interest from the corporate world is because of 
Open Source's superior quality and performance at a lower cost.  Open 
Source would have existed even without companies using it as you would 
still have those Open Source activists using it themselves in your 
product, even without the help of the corporate money. The company 
involvement in Open Source did indeed accelerate its development by 
paying many people to work on it full time.  But Open Source would still 
be there and still be in good shape even if corporate involvement didn't 
happen, just like it was before.

And this superior quality and performance characteristics of Open Source 
are not a coincidence.  They are the first motives in a world which is 
not driven by monetary profits, unlike most if not all the proprietary 
alternatives.  The people leading Open Source are driven by the 
technical excellence of their work and the recognition they get from 
their peers.  Money is a far secondary motive, and in this age you can 
choose between different sources of sufficient money not to have to 
worry about it anymore and compromise too much on your primary motives 
when you already have a track record in this Open Source world.

So to say that the corporate world might need to consider Open Source to 
be competitive and survive, but the reverse is not true i.e. Open Source 
doesn't _require_ the corporate world to survive.

> No company invests in open source for philanthropic reasons; they 
> understand that it is necessary for their businesses.  The tricky 
> problem is always in how ethical a company's usage is (and I use the 
> word 'ethical' deliberately because this is wider than mere legal 
> words smithing); whenever I give talks on GPL, I emphasise both the 
> moral as well as the legal duties.  In my experience, most companies 
> struggle to understand open source when they first start to interact 
> with it.  It usually takes some open source zealots within the company 
> to persuade their management of the right way to behave.  The best way 
> to get companies to change their behaviour is to find them and support 
> them.  Making threatening GPL noises in email does not help them in 
> any way.

Here I'm more in agreement with you.  However this is again not the full 
picture.

Ethical or not, the first motive of a company is to make profits.  If 
that was easy to get away with it, all that companies would do is simply 
to grab this body of source code for themselves and never contribute 
back. And a sizable number of companies, even some sizable companies, 
are doing just that.  While this isn't going to kill Open Source, this 
certainly makes it weaker because this is contrary to that very first 
principle that made Open Source a success in the first place.  
Companies doing that are after the immediate monetary profit and not the 
technical excellence and performances.

But even when leaving the ethical aspect aside, it is not going to be 
profitable for companies in the long term to grab Open Source results 
and move it back to the legacy proprietary model.  Doing that will be to 
their disadvantage when some other companies come along to compete on 
the market using Open Source to its fullest technical excellence and 
performance potential.  Fortunately, a sizable number of companies, even 
sizable ones, did understand that already.

But... while some companies are struggling to understand how to interact 
with Open Source, the Open Source world still dash ahead without much 
concerns for corporate profits.  As said above, those strange Open 
Source animals are motivated by the technical excellence of their work, 
and they're going to fight on that front against anything that might 
affect or prevent that goal.  This is again why Open Source has always 
progressed even despite initial attempts to kill it from some 
corporations.  So far, Linux has always been immune to monetary forces, 
whether those forces were against it or not. So it is fair to say that 
Open Source survival depends primarily on its technical advantages above 
anything else.

In conclusion: don't get surprised if technically inferior propositions, 
such as proprietary 3D libraries coupled with kernel-side interfaces, 
are met with strong or even vehement opposition.  Some people will be 
sufficiently moderated to tell you that if you want to do such thing 
then you get to deal with it all yourself and that they are not 
interested in any accommodation that would help you.  But it is clear 
that you will never get a consensus for supporting such technically 
inferior solution in the mainline tree, as from an Open Source point of 
view such a move simply makes no sense.

Accepting such things in mainline would weaken the very principle that 
as made Open source in general and Linux in particular such a success, 
while refusing it isn't going to affect the survival of Open Source 
anyway.  The compromise here would be only in the corporate world's 
favor. And as the past history has shown in such cases, the Open Source 
way always ends up prevailing eventually, despite the lack of corporate 
assistance.

So, while I'm not overly optimistic about this issue, I wish those 
companies lobbying for the weakening of the Open Source principle could 
rethink and truly evaluate the economics and actual value their 
proposition has on their long term profits, given the fact that the Open 
Source community with lower monetary ambitions is highly unlikely to 
back down on that principle.

In the end, free has its price too.


Nicolas

Re: Freescale Linux BSP review

[Tom Gall]

On Wed, Dec 22, 2010 at 11:20 AM, Nicolas Pitre
<nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Wed, 22 Dec 2010, David Rusling wrote:
>
>>       Now for a bit of a rant.  Personally, I have a deep and abiding
>> respect for open source (for me, it's the key social invention of the
>> internet age), however I also recognise that it would not exist
>> without companies using open source as part of their products.  Let's
>> face it, an awful lot of open source engineers are getting their
>> mortgages paid by companies that make use of open source.
>
> I cannot be in full agreement with the above statement.  I think the
> reality is way more nuanced than that.
>
> The truth of the matter is that Open Source came into existence without
> and despite involvement from the corporate world.  And the very reason
> it started to attract interest from the corporate world is because of
> Open Source's superior quality and performance at a lower cost.  Open
> Source would have existed even without companies using it as you would
> still have those Open Source activists using it themselves in your
> product, even without the help of the corporate money. The company
> involvement in Open Source did indeed accelerate its development by
> paying many people to work on it full time.  But Open Source would still
> be there and still be in good shape even if corporate involvement didn't
> happen, just like it was before.

Right but it didn't happen over night. Getting to this state took time
and wasn't
an immediate quality. Back in them thar early days it took a lot of
figuring out,
in some case with and some cases without the cooperation of the hardware
types. How many years did I pine for token ring drivers.... sigh.

The very important part of this whole discussion is getting arm Linux and it's
3d driver situation so it TOO is the best.

Right now it's not and pointing to other elements of the system and saying
"it's great" is besides the point.

This discussion is good, but for it to have a positive outcome, we need to
turn the direction back to how we get to the end goal
for arm 3D graphics. It's not probably going to happen at once with one
patch that does what everyone wants. I think it's going to take graduated steps
and some compromises.

Regards,
Tom
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com

Re: Freescale Linux BSP review

[Nicolas Pitre]

On Wed, 22 Dec 2010, Tom Gall wrote:

> The very important part of this whole discussion is getting arm Linux and it's
> 3d driver situation so it TOO is the best.
> 
> Right now it's not and pointing to other elements of the system and saying
> "it's great" is besides the point.

My whole point, if I may resume my conclusion to a few words, is that 
most Open Source folks don't care if you can't open your code for 
whatever reasons.  That won't encourage them to compromise on their 
fundamental principle.  It's up to those companies to balance the cost 
of maintaining their ad hoc proprietary stuff themselves vs the cost of 
opening up their code so it can be merged upstream.

> This discussion is good, but for it to have a positive outcome, we need to
> turn the direction back to how we get to the end goal
> for arm 3D graphics.

Absolutely!

> It's not probably going to happen at once with one patch that does 
> what everyone wants. I think it's going to take graduated steps and 
> some compromises.

Yes.  However, as I said, those compromises may not come on the 
technical aspects of the kernel interfaces.  Just like it is unlikely 
for companies to ever compromise on their profits.  Any compromise 
touching any of those fundamental aspects for their respective parties 
is bound to always fail.

In other words, let's save ourselves some energy and give up on the idea 
that a kernel shim only for a binary only user space library is going to 
ever be accepted in mainline.  This simply will never happen, period.


Nicolas

Re: Freescale Linux BSP review

[Piotr Gluszenia Slawinski]

> So to say that the corporate world might need to consider Open Source to
> be competitive and survive, but the reverse is not true i.e. Open Source
> doesn't _require_ the corporate world to survive.

i agree with it fully, and to support this claim i want to remind the
simple rule of capital accumulation. Open Source community
_already_ accumulated enough _capital_ in form of algorithms, 
implementations, social relations, experience, documentation and
augmentation with education system .

it can survive just fine without corporate world, while
logical relationship with organisations whole main purpose of existence
is creating profit, is to gain profit from such relationship itself.
otherwise it would be bit like Faust would just give his soul away 
completely free... and everyone knows it's not the point while dealing 
with devil.

i also understand reluctance of some people about such deals -
despite huge gains , one can loose very important things,
and end up escaping from small print obligations.
sometimes it is better to make slower, but steady progress instead.

greetings.
-- 

Re: Freescale Linux BSP review

[Konstantinos Margaritis]

On 22 December 2010 20:39, Piotr Gluszenia Slawinski
<curious-APZTmCvJ1e4cvTeJY7g42e4opr6GJZWbqwyb7XGsRfw@public.gmane.org> wrote:
>> So to say that the corporate world might need to consider Open Source to
>> be competitive and survive, but the reverse is not true i.e. Open Source
>> doesn't _require_ the corporate world to survive.
>
> i agree with it fully, and to support this claim i want to remind the
> simple rule of capital accumulation. Open Source community
> _already_ accumulated enough _capital_ in form of algorithms,
> implementations, social relations, experience, documentation and
> augmentation with education system .

I'm sorry you've got it all wrong. Survive? Yes, certainly. Actually
thrive and make a difference in the world without the corporate world?
Definitely not. If you only care about the former that's fine, but
have no illusion that we would even be having this discussion here
were it not for the corporate world caring about Linux on ARM.

Konstantinos

Re: Freescale Linux BSP review

[Nicolas Pitre]

On Wed, 22 Dec 2010, Konstantinos Margaritis wrote:

> On 22 December 2010 20:39, Piotr Gluszenia Slawinski
> <curious-APZTmCvJ1e4cvTeJY7g42e4opr6GJZWbqwyb7XGsRfw@public.gmane.org> wrote:
> >> So to say that the corporate world might need to consider Open Source to
> >> be competitive and survive, but the reverse is not true i.e. Open Source
> >> doesn't _require_ the corporate world to survive.
> >
> > i agree with it fully, and to support this claim i want to remind the
> > simple rule of capital accumulation. Open Source community
> > _already_ accumulated enough _capital_ in form of algorithms,
> > implementations, social relations, experience, documentation and
> > augmentation with education system .
> 
> I'm sorry you've got it all wrong. Survive? Yes, certainly. Actually
> thrive and make a difference in the world without the corporate world?
> Definitely not. If you only care about the former that's fine, but
> have no illusion that we would even be having this discussion here
> were it not for the corporate world caring about Linux on ARM.

Maybe.  But corporations so far have played by the Open Source rules to 
make ARM Linux what it is.  There was mutual benefits in that and ARM 
Linux did grew faster.

Having accommodations in the kernel for proprietary drivers is not a 
mutual benefit anymore.  That might be hard to understand from your 
point of view, but the incentives in the Open Source communities aren't 
based on commercial results.


Nicolas

Re: Freescale Linux BSP review

[Konstantinos Margaritis]

On 22 December 2010 21:22, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> Having accommodations in the kernel for proprietary drivers is not a
> mutual benefit anymore.  That might be hard to understand from your
> point of view, but the incentives in the Open Source communities aren't
> based on commercial results.

DISCLAIMER: I'm also a Debian developer -have been since 1999 with a
small 2y break- so I _do_ know the F/OSS community point of view. My
goals have been always in promoting open source and free software
solutions when and when not available. Right now open source solutions
are _not_ available, and that is the problem.

I haven't reversed engineered any driver so I can't claim of knowledge in this
matter. However I've been following closely other such projects like nouveau
and it took them a _long_ time to get to this point here -which may be usable
for many people, but it's not even at a beta state according to the Nouveau
developers. Even if we assume the fact that 10 times more ARM F/OSS
developers gather to reverse engineer the binary blobs, how long do you think
it would take until a beta driver appears? 1 year? 2 years? And what will happen
in the meantime?

I'm not advocating that closed source drivers be included in the
kernel, but IMHO,
having an open kernel-space driver would also help the reverse engineering
process at the same time as allowing common users as well as developers to
use and test any 3D applications -don't forget that 3D problems don't
end at the driver,
rather the opposite.

Konstantinos

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Freescale Linux BSP review

[Dave Airlie]

>
> I'm not advocating that closed source drivers be included in the
> kernel, but IMHO,
> having an open kernel-space driver would also help the reverse engineering
> process at the same time as allowing common users as well as developers to
> use and test any 3D applications -don't forget that 3D problems don't
> end at the driver,
> rather the opposite.

Again thats a short-term view. So we spend the effort to clean up the open
kernel code, but the vendors want to keep the interface to userspace the
same so the binary modules can keep functioning? How do we clean up
insanities in the interfaces? How do we optimise the stack going forward?

Having the code in mainline won't help anyone who is any good at
reverse engineering.

Dave.

Re: Freescale Linux BSP review

[Nicolas Pitre]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2915 bytes --]

On Wed, 22 Dec 2010, Konstantinos Margaritis wrote:

> On 22 December 2010 21:22, Nicolas Pitre <nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > Having accommodations in the kernel for proprietary drivers is not a
> > mutual benefit anymore.  That might be hard to understand from your
> > point of view, but the incentives in the Open Source communities aren't
> > based on commercial results.
> 
> DISCLAIMER: I'm also a Debian developer -have been since 1999 with a
> small 2y break- so I _do_ know the F/OSS community point of view. My
> goals have been always in promoting open source and free software
> solutions when and when not available.

Good to know.

> Right now open source solutions are _not_ available, and that is the 
> problem.

Yes, everyone agrees.  Well, I suppose.

That would be the first official statement to make.  Do we really 
consider this a problem?  Because most companies used to the proprietary 
model won't see a problem at all here, and therefore wouldn't consider 
any effort in the direction of open drivers a worthy goal. That would be 
the heart of any subsequent misunderstandings.

I'll let someone else with a bigger Linaro hat make that official 
statement though.

> I haven't reversed engineered any driver so I can't claim of knowledge in this
> matter. However I've been following closely other such projects like nouveau
> and it took them a _long_ time to get to this point here -which may be usable
> for many people, but it's not even at a beta state according to the Nouveau
> developers. Even if we assume the fact that 10 times more ARM F/OSS
> developers gather to reverse engineer the binary blobs, how long do you think
> it would take until a beta driver appears? 1 year? 2 years? And what will happen
> in the meantime?

In the mean time some other company might see a nice opportunity to 
sidestep the competition by making its drivers fully open source.  
That's what happened with WIFI, resulting in the least expected company 
to finally open up its driver like all the others ended up doing.  It 
must have been economically advantageous to them in the end (lower 
support costs, additional customer opportunities, etc.)

> I'm not advocating that closed source drivers be included in the 
> kernel, but IMHO, having an open kernel-space driver would also help 
> the reverse engineering process at the same time as allowing common 
> users as well as developers to use and test any 3D applications -don't 
> forget that 3D problems don't end at the driver, rather the opposite.

Problems don't end at the driver, they start there.

And those proprietary drivers exist and are being used already.  But 
don't expect the mainline kernel to make accommodations for them. It is 
not economically viable for the Open Source community to accommodate 
proprietary drivers, irrespective of how loud you might advocate for 
that.


Nicolas

[-- Attachment #2: Type: text/plain, Size: 175 bytes --]

_______________________________________________
linaro-dev mailing list
linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Freescale Linux BSP review

[Xavier Bestel]

Le mercredi 22 décembre 2010 à 15:29 -0500, Nicolas Pitre a écrit :
> It is 
> not economically viable for the Open Source community to accommodate 
> proprietary drivers, irrespective of how loud you might advocate for 
> that.

I think you can remove the word "economically" from your sentence (or
replace it with e.g. "technically"), and it's all the more true.

	Xav

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Nicolas Pitre]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 569 bytes --]

On Thu, 23 Dec 2010, Xavier Bestel wrote:

> Le mercredi 22 décembre 2010 à 15:29 -0500, Nicolas Pitre a écrit :
> > It is 
> > not economically viable for the Open Source community to accommodate 
> > proprietary drivers, irrespective of how loud you might advocate for 
> > that.
> 
> I think you can remove the word "economically" from your sentence (or
> replace it with e.g. "technically"), and it's all the more true.

I used that word on purpose. Economic principles do exist in the Open 
Source world too.  It is just not based on monetary profits.


Nicolas

[-- Attachment #2: Type: text/plain, Size: 175 bytes --]

_______________________________________________
linaro-dev mailing list
linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Freescale Linux BSP review

[Piotr Gluszenia Slawinski]

> it would take until a beta driver appears? 1 year? 2 years? And what will happen
> in the meantime?

plainly.some other company will take over the market, and sell products 
with open drivers available.
in meantime arm devices can still be used for i.e. dataloggers, especially
without linux support their market price drops significantly.

i really see no big deal here. it happened before with nvidia -
don't you recall how much their hardware lost in it's value ?
upgraded cards were given-away as buggy and unsupported in linux,
and had very short-life in 2nd hand market.
compare it to i.e. SGI machines which are still circulating and are 
valued, even though their opensource support is actually not so brilliant, 
and hardware performance even worse...

nowadays companies like ARM are again fishing in the same market - people 
who once invested big bucks in nvidia, are now thinking twice.
and it's not really related with opensource - notice how many unsatisfied 
customers turned away from _proprietary_ solutions , tired with messy 
service packs, remote exploits, long-uncorrected bugs, and dropping of 
support for whole OS solutions, leaving users with expensive support 
options and unstable systems behind.

i think if new ARM/freescale products will not have decent opensource 
support now, they will not only loose opensource market, but will not get 
the profit from proprietary market basing on previous 'success' of 
similiar solutions due fact users simply learnt their lesson.


-- 

Re: Freescale Linux BSP review

[Piotr Gluszenia Slawinski]

> On 22 December 2010 20:39, Piotr Gluszenia Slawinski
> <curious@bwv190.internetdsl.tpnet.pl> wrote:
>>> So to say that the corporate world might need to consider Open Source to
>>> be competitive and survive, but the reverse is not true i.e. Open Source
>>> doesn't _require_ the corporate world to survive.
>>
>> i agree with it fully, and to support this claim i want to remind the
>> simple rule of capital accumulation. Open Source community
>> _already_ accumulated enough _capital_ in form of algorithms,
>> implementations, social relations, experience, documentation and
>> augmentation with education system .
>
> I'm sorry you've got it all wrong. Survive? Yes, certainly. Actually
> thrive and make a difference in the world without the corporate world?
> Definitely not. If you only care about the former that's fine, but
> have no illusion that we would even be having this discussion here
> were it not for the corporate world caring about Linux on ARM.

survive, and serve. despite corporate entities, opensource projects
do not just cease to exist once markets cut the profit down.
this is where corporations loose big time in comparison to opensource.

thrive? come on, discussion starts about small, insignificant toys, and
i repeat - insignificant toys. talking big about '3d in linux'
as any priority sounds funny in world in which 99% of the tcp/ip routing 
is performed by opensource-based solutions, at both enterprise , and
'home' scale. while opensource display system has enough proprietary 
alternatives to choose from at low cost, point of developing it lies
far beyond just cutting few pennies for ... toys. this can be done
without opensource at all.

talking about opensource unable to survive without care of corporate world 
is also funny. current opensource politics allowed such growth thanx to
proper politics when it came to dealing with corporate world. without
opensource certain solutions would never propagate and become 
cost-effective to gain enough markets. so profit opensource gained from it
is fair-earned, and comes from market itself, not from corporate world
attitude. in other words - if certain corporations would not partake 
certain attitude, it would be done by other ones, or certain products 
would just never existed.

still _opensource_ would be same good as before, 
as notice development of certain algorithms and code was conducted in 
parallel, and also sponsored by university environments for solely 
research and educational purposes (to exclude any opensource-ideology 
driven motives) .

my 2 eurocents ;)
-- 

Re: Freescale Linux BSP review

[Alan Cox]

>  way to behave.   The best way to get companies to change their behaviour is to find them and support them.  Making threatening GPL noises in email does not help them in any way.

I would disagree based on years of history.

The best way to get a company to change behaviour is for a situation to
occur in which it is in their own hardcore capitalist self interest to
change.

In my experience open source usually mirrors standards in this. The
leading vendors refuse to take part, the smaller vendors see the
opportunity - often working together - and the bigger vendor eithers gets
its backside kicked or does a sharp turn in the right direction.

That's the story of email, of the web, and is occuring currently in
telephony and other areas.

It's also why folks like Dell deserve a lot more credit than they get for
the success of Linux.

If its not commercially sensible it doesn't matter what the licensing
says. They are corporations not charities, if it's not economically
viable for them to manage it all themselves including new driver
releases, legal risk, all their own review and keeping up with DRI then
they have to decide which way to go - some go the "hit and run" approach
('not got kernel X then sorry but not our problem'), some do the work to
support it release by release but don't go GPL (eg Nvidia), some open up,
others just walk away.

Alan

Re: Freescale Linux BSP review

[David Rusling]

Alan,
	I still stand by my assertion that educating companies as to the realities and philosophies of open source is better than threatening them.   Your analogy of  open source as a standard, a practical de facto standard written in a programming language is a good one.    Forking code (by never upstreaming it) tends not to be sustainable (although some companies still try).    Proprietary code exists for all sorts of reasons, often a bogus belief in an intrinsic value.    Graphics, in particular, is a very litigious world and also, the biggest cause of proprietary code, surely some link?

	Back to the plot.   Linaro is trying to help here, both in reducing non-optimal code forking and in helping its members work better with the open source communities.   As I said in my earlier mail, this will take time.   That said, I've seen enormous shifts within the ARM partnership already this year and look forward to more next year.

	Merry Christmas / Happy Holidays to one and all.
Dave

ps nice to see that you keep your old email address.    Are you still in Wales?

On 23 Dec 2010, at 17:17, Alan Cox wrote:

>> way to behave.   The best way to get companies to change their behaviour is to find them and support them.  Making threatening GPL noises in email does not help them in any way.
> 
> I would disagree based on years of history.
> 
> The best way to get a company to change behaviour is for a situation to
> occur in which it is in their own hardcore capitalist self interest to
> change.
> 
> In my experience open source usually mirrors standards in this. The
> leading vendors refuse to take part, the smaller vendors see the
> opportunity - often working together - and the bigger vendor eithers gets
> its backside kicked or does a sharp turn in the right direction.
> 
> That's the story of email, of the web, and is occuring currently in
> telephony and other areas.
> 
> It's also why folks like Dell deserve a lot more credit than they get for
> the success of Linux.
> 
> If its not commercially sensible it doesn't matter what the licensing
> says. They are corporations not charities, if it's not economically
> viable for them to manage it all themselves including new driver
> releases, legal risk, all their own review and keeping up with DRI then
> they have to decide which way to go - some go the "hit and run" approach
> ('not got kernel X then sorry but not our problem'), some do the work to
> support it release by release but don't go GPL (eg Nvidia), some open up,
> others just walk away.
> 
> Alan

Re: Freescale Linux BSP review

[Jerome Glisse]

On Wed, Dec 22, 2010 at 6:02 AM, Konstantinos Margaritis
<markos-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> wrote:
> On 22 December 2010 09:51, Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> wrote:
>> Okay I hereby refrain from legal comments.
>>
>> In any case, this code has passed legal at Freescale and AMD *AND*
>> Qualcomm. It would not be GPL if it has not been vetted (and it took
>> them a year to get to this point).
>
> It appears that this discussion ended up on phoronix.com [1], with an
> air of hostility towards Genesi and Matt for no good reason.
>
> I don't know whose idea was that, but it's certainly of very bad taste
> and helps very little to the discussion. Matt poses real questions and
> issues we -as a company producing ARM products- face all the time.
> Admittedly the technical reasons for not including the kernel-space
> driver into mainline presented by Dave Airlie are correct and very
> down-to-earth. But IMHO, *this* should be the starting point to
> continue the discussion, instead of immediately rejecting this driver.
> Is there *any* way that problem posed by Dave could be solved, perhaps
> by throwing the ball to the ARM vendor companies to provide just a
> small extra part of the code needed to do API checks and therefore
> ensuring the kernel guys CAN actually do their work as they like?

It's not enough to provide a toy program/library that just call into
the new kernel API, you really need to provide a full open source use
case that does achieve somethings using the new kernel API you are
introducing. It's the only way we can possibly evaluate the new API.

Open source GPU kernel API are a pain to design and i can tell you
that if i had liberty to change them i would do that a lot until
finding the best one (nouveau is in happy situation here and they are
more than right to wait until they are completely satisfied with the
API before freezing it).

> As for the philosophical problems, well, I'm sure everyone here
> understands that the situation of ARM graphics in the kernel is in no
> way comparable to Intel or Nvidia/ATI chipsets, they had totally
> different starting points. ARM came from the embedded market where it
> thrived for many years with the exact same licensing rules that we all
> would like to abolish in just a few months, where at the same time we
> "swallowed" the fact that it took Intel and ATI/AMD - forget nvidia,
> nv-obfuscated driver IN the kernel for YEARS? really? - many years to
> accept mainline opensource development. And even Intel with all their
> experience made a complete mess of things using the latest cpus.

No body is saying AMD or Intel were fast to jump into open source,
doesn't mean that ARM ecosystem can't do it faster than AMD or Intel
did.

> I *really* do appreciate Linaro and the effort from ARM and the
> relevant vendors towards open source enablement, and Genesi has proven
> that by donating ~50 ARM based netbooks and smarttops to Linaro
> developers at Linaro@UDS -and around ~40 units to other projects
> including Debian and Gentoo -and we intend to give more in the future.
> We know the process and how it works, just as well as everyone here
> does actually. But we also have to be pragmatic. An ARM based
> solution/product with no long-term support from the kernel side will
> find it very hard to survive indeed. I strongly believe that, half a
> solution is better than no solution, and it can also serve a purpose
> until a proper full solution appears. It also does show a leap of good
> faith from the FOSS side, and one which ARM companies will have to
> follow soon.
>
> So, if by chance anyone really expects ARM licensees to do 180 degrees
> change in philosophy overnight, I obviously cannot speak for them, but
> IMHO, that is not bound to happen. It will probably happen in a few
> years but only by discussion and collaboration, seriously not by
> dealing with absolutes. Denying even the smallest step backwards from
> the side of the FOSS community is not a victory, it's a downright
> failure of the community side to actively support and push ARM -based
> devices as an alternative Linux desktop and portable solutions
> (netbook etc).
>
> My 2c.
>

Cheers,
Jerome Glisse

Re: Freescale Linux BSP review

[Alan Cox]

> The GPLv2 is written such that the "if you're interfacing the kernel
> or compiler you don't need to opensource that bit with your app"

I would suggest you re-read the license. It says nothing of the sort.
Indeed the gcc compiler licensing for the compiler support library is
actually rather carefully done for this reason.

> You may think it's a horrible idea, and from a technical perspective
> it is, but from a legal perspective.. it's not a problem.

I would suggest you re-read the detail on derivative works, from a legal
not a computer science point of view. You may want to read up on the
history of the dispute between Next (the computing not the clothing firm)
and the FSF with regards to the Objective C compiler.

Note also btw that the possibility of accidentally including general user
space was a concern which is why there is a rider with the kernel COPYING
file - for the standard syscall interfaces only. There is a difference
between a derivative work and merely using an interface and there are
lots of ways works can be derivative or not that usually surprise people
who think in models around code. The fact these can work in weird and
wonderous ways is one reason for that rider.

> grounds, and policy grounds. There is no legal issue here. It is not

That is a point only a court of law can decide. It's something I do spend
time discussing with lawyers and I have to say not one of them considers
there to be no legal issue. The actual boundary for such things is
extremely grey and ill defined in software, although there is a lot more
caselaw in comparable other areas (anthologies and compilations versus
for example music as film scores, or combining two pieces of music to
make one tune)

> concept now... what's the point? It'll never get into mainline.

Unless it is open sourced - ditto the various other things with the same
problem - including things like the Intel PSB driver.

Alan

Re: Freescale Linux BSP review

[Matthew Garrett]

On Mon, Dec 20, 2010 at 10:18:21AM -0600, Matt Sealey wrote:
> Ownership of the code is dependent on who licensed it. I do not think
> Linaro need be so concerned over opensourcing or reimplementing
> drivers. The fact that the kernel driver is open source as it is, and
> this is by far the most important part. The userspace library is
> closed because it is proprietary; and I think it is well outside
> Linaro's remit to lobby for opensourcing of proprietary code simply to
> meet an esoteric and needless demand for source code access (as it
> stands, you can get source code access by signing the usual plethora
> of NDAs with the appropriate vendor, as Genesi has done). It is my
> understanding that Freescale/AMD and Qualcomm maintain seperate forks
> of the driver and do not cooperate on development, and in any case,
> Linaro does not include Qualcomm anyway, therefore it is also to my
> understanding that this discussion is also beyond Linaro's remit.

Given that upstream policy is to refuse DRM components unless there's an 
open userspace consumer of the interface, whether or not this 
conversation has any purpose is entirely down to whether Linaro's kernel 
policy is to limit itself to upstreamable code or not. If Linaro's 
reference kernel is intended to include nothing but code that's on track 
to become mainline then asking whether there's any way these drivers can 
be merged is a useful question. If Linaro's reference kernel is intended 
to include whatever's necessary to get hardware working, 
upstream-suitable or otherwise, then there's not much point in worrying 
about it.

-- 
Matthew Garrett | mjg59@srcf.ucam.org