Re: autobuild system of linaro
Hi, On 12/15/2010 09:28 AM, Paul Li wrote: > Hi, > > > > If I want to build the system from scratch, what should I do? I > mean, where to get the deb binary packages of Linaro? Where to get the > image creator tool? etc. thank you. > > > B.R > > Paul Did you manage to build a Linaro image from sources? How? I'm trying to do something similar. Would like to build the last official release for the beagle-xm and/or be able to add executables to it. This means that I would need headers and libraries. Regards, Robert..."Experience is the worst teacher. It always gives the test first and the instruction afterward." My public pgp key is available at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Weekly Release Meeting Cancelled
Hi, Due to the holiday season many key people are on vacation at the moment. For this reason the weekly Release Meeting has been cancelled. The next meeting will be Wednesday 5th January 2010. Regards, Jamie. -- Linaro Release Manager ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
On 22 December 2010 09:51, Matt Sealey 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 lin...@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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
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 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. Dave David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
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. -- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
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? -- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
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
Re: Freescale Linux BSP review
On Wed, Dec 22, 2010 at 11:20 AM, Nicolas Pitre 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: autobuild system of linaro
Hi Robert, I don't know if Paul was successful but I do "build systems" from the linaro/ubuntu packages so I suspect I can probably be of some assistance. This might be something better discussed interactively rather than via email but either way. You might want to join #linaro on irc.freenode.net. When you're looking "build from scratch" are you intending on rebuilding everything with your own compiler options etc etc or are you looking to assemble a usable system from the already built package set that we have? If it's the latter this wiki page will probably be of interest to you: https://wiki.linaro.org/LiveHelper/Hacking It discusses how to build your own system images using live helper. 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 On Wed, Dec 22, 2010 at 3:09 AM, Robert Berger wrote: > Hi, > > On 12/15/2010 09:28 AM, Paul Li wrote: >> Hi, >> >> >> >> If I want to build the system from scratch, what should I do? I >> mean, where to get the deb binary packages of Linaro? Where to get the >> image creator tool? etc. thank you. >> >> >> B.R >> >> Paul > > Did you manage to build a Linaro image from sources? > > How? > > I'm trying to do something similar. > Would like to build the last official release for the beagle-xm and/or > be able to add executables to it. > > This means that I would need headers and libraries. > > Regards, > > Robert..."Experience is the worst teacher. It always gives the test > first and the instruction afterward." > > My public pgp key is available at: > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1 > > > > ___ > 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
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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
On Wed, Dec 22, 2010 at 6:02 AM, Konstantinos Margaritis wrote: > On 22 December 2010 09:51, Matt Sealey 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 lin...@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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
On 22 December 2010 20:39, Piotr Gluszenia Slawinski 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
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. -- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
On Wed, 22 Dec 2010, Konstantinos Margaritis wrote: > On 22 December 2010 20:39, Piotr Gluszenia Slawinski > 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
On 22 December 2010 21:22, Nicolas Pitre 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
> > 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. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
On Wed, 22 Dec 2010, Konstantinos Margaritis wrote: > On 22 December 2010 21:22, Nicolas Pitre 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___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
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___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PM] 22/12/2010 - Minutes for the Power Management WG weekly call
Hello Everyone, The minutes of the weekly call can be found at: https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2010-12-22 Attendees: Vishwa, Torez, Vincent, Yong Regards, Vishwa ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
