Re: idea for running out of RAM
On Mon, 29 Sep 2008, Hal Murray wrote: > > One would adjust the shading in each activities portion of the circle. White > for not used and black for used. (Red for over allocation?) > > The other would be to use the applications chunk of the circle as a pie > shaped bar graph. The black section would show what % of the allocated > memory was currently in use. Maybe a ring with shared memory "protruding" inside and allocated but not-paged-in memory "protruding" outside? -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Networking] TCP is broken in mesh mode
On Wed, 11 Jun 2008, Trent Lloyd wrote: > Keep in mind however that the other traffic, i.e. discovering the > other XO is a multicast packet and therefor would be routed on the > mesh somewhat differently AIUI (its basically re-broadcasted by every > node?) > > Thus I suspect the issue is the nodes simply have no direct > communication at all given the lack of replies to the ARP packets.. > and any "other" tcp or ping is not going ot work if arps simply aren't > being replied to, as ARPs are in no way specific to the connection type. > > Thus I suspect the issue is that multicast forward is working (which > seems perfectly sane mentally, given what I know as the difference > between how unicast and multicast work on the mesh) but the direct > node-node path is totally broken and this would be a relatively > pointless excercise. > > I guess getting the mesh neighbour tables per Bill's email would be > the most useful step forward. And arp tables, that will give the idea if ARP responses were received and used to correctly update the tables. -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-2
C. Scott Ananian wrote: > On 5/22/08, Alex Belits <[EMAIL PROTECTED]> wrote: >> Carl-Daniel Hailfinger wrote: >>> I believe item k) was already in the contracts with Quanta and Marvell, > > Just to clarify: Carl-Daniel is not an OLPC employee, and is not > speaking for OLPC. > >> I am still trying to find out, whom am I supposed to ask at Marvell to give >> the documentation and/or pieces of whatever source Marvell can release (in >> whatever shape) to me and other volunteers interested in work on wireless >> firmware, so we can make an open source version of libertas firmware. It >> looks like everyone is discouraged to even hope for it at this point. > > http://wiki.laptop.org/go/Marvell_microkernel My name is uselessly gathering dust on that page for two months already. > A more constructive suggestion might be to support > http://open80211s.org/ , which is basically all of the wireless > firmware except the lowest-level hardware-specific stuff. Except the project is about Linux driver, not firmware. The whole reason why Libertas chipset was chosen, was the fact that it can perform mesh routing by ARM-based system-on-chip wireless chipset while kernel is not running on the main CPU, thanks to extremely thick "lowest-level hardware-specific stuff" -- a large piece of stack implementation in firmware on the ARM side. Please look at http://dev.laptop.org/ticket/2177#comment:9 to get the idea what level of control does the Linux driver have in this model. I guess, we can abandon that model and use completely host-implemented mesh (with open80211s code), however if we will do so, power management goes right out of the window -- kernel should be awake to run this. -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Release process
Jim Gettys wrote: > I will note that "testing" in Debian wasn't a good place to live for a > very long time: it didn't get timely security updates, and consequently, > no one ran it (so it got minimal testing, despite its name). Except for Sarge. There was a three-year interval between "Potato" and "Sarge" stable releases, so toward the end of the process server users had to migrate to then-testing Sarge to be able to use modern versions of software. At approximately the same time Ubuntu was started, with one of distinctions from Debian being stable releases twice a year. -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-2 software plans
Jim Gettys wrote: > Bert... > > Part of the problem is the X driver model is pretty broken, causing much > more to be done in software than should be necessary; and it isn't clear > we're even using X efficiently at the moment... The driver stuff is > getting fixed (in general in X: this is the EXA/DRI2 work); profiling of > our entire software stack is in order to see where our real problems are > at the moment. EXA? DRI2? Don't you end up using Cairo through GTK as the main layer that almost everything goes through, so everything below has any importance only as long as Cairo uses it efficiently? Don't the most important speed limitations come from the need to support interpreter-based, easy-to-develop-for environment? Scaling works fine where it's necessary (video), however it will be of no help for most of the user interface. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Its.an.education.project] Constructionism (was Re: XP on OLPC - a contrarian view)
Eben Eliason wrote: > For what it's worth, I would be careful to portray "the low-achievers" > and "the brightest" as opposites. As I note below, I frequently find > that some of the brightest are also some of the low-achievers, due to > certain aspects of the educational system. This doesn't change your > point, of course, which is noted. It simply means that the way we go > about raising the overall educational level might not be as > straightforward as many think. What is important, higher overall education level ALWAYS benefits society given other equal conditions, and lower overall educational level ALWAYS hurts it. Ex #1: The above mentioned Republicans (or to be more precise, Social Conservatives that in US are represented by Republican Party) who are mostly supported by either rich or ignorant. Ex #2: Modern industrial development that contrary to the popular belief goes well in any social and economic system as long as skills and education level that society provides are sufficient to develop technology locally (such as all parts of "China" -- PRC, ROC and Hong Kong). Social development follows the economy that in its turn follows education, science and technology, what, of course, depends on social development. Ex #3: Countries that made their bet on developing specific and narrow industries and skills oriented entirely for export (Mexican industry in the past, current Indian remote technical support and software development) only to lose demand after greener/cheaper pastures become available to foreign importers of their services. Real education is not a machine tool operator manual, or an English textbook and a phone script. >> * What has gone wrong that teaching to the test so often ends up being seen >> as being in conflict with teaching to the skills ? To the extent that often >> teaching to the skills is neglected ? Why there ARE tests that are not a part of the teaching process in the first place? US turns everything into some kind of adversarial system where government acts as both public schools' owner and adversary that challenges schools with tests instead of co-operating with them, thus basically not trusting its own employees to do their job, and doing it through students for whom both government and teachers are supposed to be figures of authority. From student's point of view it's about the same as a customer going into a bank only to become an unwilling participant in a fire or bank robbery drill every month. > I don't think this is the fundamental problem; teaching to the test > can happily coexist with teaching to the skills, in theory. In > practice, I feel that this is seldom the case, because the "teaching" > doesn't happen in a manner which actually imparts true understanding > of the concepts. That is, teaching to the skills frequently manifests > itself as memorizing to the skills, which might provide short term > results (in the form of good test scores and further funding), without > providing any long term educational benefits. The means are put > towards the wrong ends (the test scores, not the learning). When tests exist to evaluate students' progress, and minimum curriculum is already predetermined, tests are not a problem at all. When "minimum curriculum" only exists disguised as "standardized tests" and the fundamental relationship between the entity that determines the curriculum and the entity that teaches it is adversarial, tests serve a completely different purpose -- evaluating school in the eyes of the government. If government was confident that schools' actions are always directed at teaching the curriculum, the need for government tests would be eliminated, however thanks to US federal/states/local split schools have to serve three masters -- two with money, one with local political influence (and occasionally with saddled dinosaurs). >> * What has gone wrong that the claim "it is extremely important for society >> that we raise the educational level of the low achievers" is so often used >> as the justification for "a system which does not do much for the brightest" >> as if this the only way things can possibly be ? > > This is another big problem. Clearly in the top-down > teach-as-the-source-of-knowledge model, more attention is often given > to those who need help. Understandably so. One might even argue that > this is expected, since the bright kids are not only capable of doing > the required work, but are often self-empowered learners capable of > going beyond that which is required. In practice (at least in my > experience), two things get in the way. First, I have seen the bright > ones who "get it" actively discouraged from going above and beyond by > teachers, who desire to keep everyone at the same level. Second, some > of the bright ones who lack a real challenge often lack (or lose) the > desire to put in any further effort at all; it's boring. Not to mention, without a learning proc
Re: [IAEP] [sugar] OLPC's bizarre behaviors
Steve Holton wrote: > You missed a step. ;-) > > The 'what it will be' statement is usually derived from (and guided > by) the 'what it must be' statement. > Step 1 (the 'what it must be') is the list of Requirements. > > From the requirements we can dual track derive the possible > implementations which will meat those requirements and the set of > tests to ensure the requirements are met. Without the requirements as > a guide, we get the wild (and distracting) speculation, the missteps, > deficient features, etc. > > From the requirements we can ask questions like: > - Is this feature (a touch screen, for example) a requirement? > - What other features are dependent on this feature? > - If we decide to remove this requirement, of change fundamental > intervaces or attributes, who will need to be notified? > - What other features is this feature dependent upon? Public participation in discussion about hardware design choices? I guess, I got so accustomed to the lack of communication, such an idea didn't enter my mind. To be fair, I can understand lower expectation of getting good hardware design from community input rather than software (software developers already working using open source, hardware designers still tied to closed development model). So I am not really surprised about hardware not being discussed, but I see replacement of clear communication with "evil open source fundamentalists" in favor of CG dog and pony show as seriously counterproductive. -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC's bizarre behaviors
Bert Freudenberg wrote: > But seriously, the new design needs to be anticipated by the developer > community, development from now on should take into account the future > hardware directions. So I for one hope that developers will be > informed of anticipated hardware changes as early as possible. And > hopefully even early enough to give feedback. Then the announcement should be: 1. Primarily to developers, in a much less pompous form, and without "artwork". 2. Be in the form of "Next device within two years timeframe will likely have a large, possibly dual, multitouch touchscreen and a keyboard may be implemented in the same way (with or without touchscreen underneath, and with or without key mechanism on top)". That would clearly communicate the tasks (touchscreen-friendliness of UI, inclusion of latest development in input technology), avoid miscommunicating commitment to all details of a particular announced CG drawing (dual screen? lack of keyboard? no camera? particular size? those are likely to change before the final product), and show commitment to using pieces of existing technology. I am surprised how things that can be done in a clear, productive and inoffensive way end up being showcases of miscommunication, cause all kinds of hurt feelings, and actual information has to be derived through over-analysis and guesswork. -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-2 software plans
Chris Ball wrote: > Hi Alex, > >> That's assuming that non-OLPC developers will have access to >> hardware before it will be declared ready for deployment. Otherwise >> it will be like G1G1 -- first batch to outside developers coincides >> with first mass deployment, then everyone complains that deployment >> happened before development. > > This isn't true at all. I got my first hardware, as a non-employee with > no relationship to the project, in May 2006. We'd sent hundreds of > laptops out via the public developer program by the time G1G1 happened. How many developers were in that program, and how can one join it? Is it available now, between G1G1's? -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help regarding Sugar on Ubuntu
Waqas Toor wrote: > Hello, > > On Fri, May 23, 2008 at 11:16 AM, Alex Belits <[EMAIL PROTECTED]> wrote: >> Waqas Toor wrote: >>> 1024x786 becomes full screen mode in my ubuntu, what I want to do to >>> make it a smaller screen size and the aspect ratio of the frame/canvas >>> should adjust accordingly, Full screen mode does wierd things :) >> If you use sugar-emulator, this is a problem (I wouldn't call it a bug >> because I have no idea what should be the desired behavior) in >> /usr/sugar/shell/emulator.py in code starting from the line >> >> "if gtk.gdk.screen_width()" ... >> > yup I have done the same thing, but this happens only for the Xephyr, > the emulation under the Xephyr wont adjust itself , > The icons and frames remain of bigger size, they wont adjust according > to the Xephyrs' new size :( Xephyr dpi is set in the same script. -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-2 software plans
John Gilmore wrote: > It'll be hard for OLPC to get multi-touch working when for the last 15 > months they haven't had the bandwidth to figure out whether the > current touchpad can do "tap to click" (ticket #959). But developers > and users of devices built between now and then will write most of the > software needed. The free software ecosystem will save the day again. That's assuming that non-OLPC developers will have access to hardware before it will be declared ready for deployment. Otherwise it will be like G1G1 -- first batch to outside developers coincides with first mass deployment, then everyone complains that deployment happened before development. -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-2
Albert Cahalan wrote: >> I can think of a few ways to integrate a keyboard with this new design. >> But then we continue the huge production/logistical problem of >> generating keyboards (and spares keyboards) for each country. > > For generating them, you could do something more like an ink-jet. > Then you don't have to retool the factory to change things. > Write a mirror image into the mold for durability. > > A flex keyboard with hard keycaps would have been lovely to type on. > It can be done; you just need a hardness gradient like the squid: > http://science.slashdot.org/article.pl?sid=08/03/29/237206&from=rss It should be possible to make a touch-sensitive "keyboard/touchpad" layer that can be placed either on a screen or smooth plastic surface, then decide if the device is going to have that second screen. Regardless of that decision, it should be possible to provide separate keyboard mechanisms (XO-1-like, regular laptop scissor keys, "clicky" keys) that can cover the sensor for easier typing, and can be mounted over a touchscreen with some pins and slots, clamp in hinge, etc. If the keyboard mechanism breaks, it will be possible to remove it and continue typing directly on the sensor using printed or on-screen keyboard image until the replacement keyboard arrives. For some activities the keyboard can be removed or replaced with a special layout (piano keys, audio or video mixer or editor, vehicle-like controls). -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help regarding Sugar on Ubuntu
Waqas Toor wrote: > 1024x786 becomes full screen mode in my ubuntu, what I want to do to > make it a smaller screen size and the aspect ratio of the frame/canvas > should adjust accordingly, Full screen mode does wierd things :) If you use sugar-emulator, this is a problem (I wouldn't call it a bug because I have no idea what should be the desired behavior) in /usr/sugar/shell/emulator.py in code starting from the line "if gtk.gdk.screen_width()" ... It determines if it should run Xephyr in fullscreen or windowed mode by the size of the screen, so to fix that behavior you can edit the line (that contains the condition for choosing the fullscreen mode) and subsequent lines that determine arguments to Xephyr. -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC's bizarre behaviors
C. Scott Ananian wrote: > I'm not sure exactly what you mean. About a million kids will be > using the XO-1, in *just this calendar year*. The XO-2 will not be > ready until 2010 at the earliest. How do you feel that the XO-1 is > merely a test bed? > > This is a serious question: if this impression is widespread, we need > to do a better job communicating, and your help in discovering what we > still haven't said is important. (See > http://lists.laptop.org/pipermail/devel/2008-May/013694.html for my > previous best effort.) I disagree that XO-2 announcement really makes it look like XO-1 was a "test bed", however I still see it as being extremely poorly timed. XO-1 still has multiple unresolved issues that users see as serious defects. It has one issue that *I* see as a serious defect (SD corruption), it's just being a kernel developer I am less likely to blame anyone but myself for not working on it. There already was a serious shortage of good will toward the project due to Negroponte badmouthing Open Source development in public. Microsoft announcement of their "$3" Windows XP makes everyone suspicious about existence of some backroom agreements or even payoffs. Then Negroponte openly announces "alliance" with Microsoft that all but confirms people's worst fears. Then we hear about plans for finding some "third parties" that will port Sugar to Windows despite the fact that such a project has no popular support inside or outside current Sugar development that is, on top of everything, is in a state of flux and organizational transition. At this moment, when everyone is trying to find out what the direction of development and deployment of XO-1, Sugar or XO-with-XP is going to be, when the answer to that question will determine which people are going to participate and support the project, and which people will dedicate their time, influence and energy to damage the reputation of OLPC (BTW, I can go into either of those categories depending on actual answers that I still don't know) -- at this moment what is the most damaging thing Negroponte can do short of shutting down the project or "donating" it to Bill Gates, SCO or other similarly odious entity? Right, it's to make a "big announcement" that addresses none of those questions, and provides no information that is going to be relevant to the public for at least two years (and likely longer because development timeframe sounds pretty unrealistic in the absence of massive volunteer support). If I was anywhere close to OLPC management I would recommend to avoid any announcements before they can clearly and unambiguously announce some kind of position and plans for continuing development of the current project that can be seriously taken as immutable for the foreseeable future. Especially announcements that require 3D mockups in place of actual prototypes. -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-2
Carl-Daniel Hailfinger wrote: > I believe item k) was already in the contracts with Quanta and Marvell, > unless the official announcements back then were wrong. It has been > stated repeatedly by OLPC officials that the only thing preventing a > full open source wireless firmware is the lack of time for porting the > code to another embedded OS. What? I am still trying to find out, whom am I supposed to ask at Marvell to give the documentation and/or pieces of whatever source Marvell can release (in whatever shape) to me and other volunteers interested in work on wireless firmware, so we can make an open source version of libertas firmware. It looks like everyone is discouraged to even hope for it at this point. If Marvell people actually said that the only reason is lack of resources on their side, there are non-Marvell people willing to do that. All Marvell has to do is to release whatever materials they can release -- some even under NDA as long as it won't interfere open source software development. Marvell done that in the past with their other hardware, and there is no reason (other than "they are stealing our preciou code" and "we are too embarrassed to show it to a professional programmer, he will laugh at us") not to do it this time. The quoted paragraph almost makes it look that I should ask OLPC management so they can ask Marvell, however something tells me that this is the same kind of statement as "We added SD slot for Microsoft!" (in other words, outright lie). -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Its.an.education.project] Constructionism (was Re: XP on OLPC - a contrarian view)
Walter Bender wrote: > The week culminated with an open-house where each teacher > presented a project they developed that integrated national curriculum > goals into an XO activity. I think, this illustrated another, probably less fundamental but practically important point -- if a country has national curriculum, the whole educational system treats it as the foundation of their work, and whatever tools or methods are introduced are judged by their suitability to fit in it, or at least by being compatible with it. No one would dare to remove a chunk of curriculum to replace it with some other content -- it will break all kinds of dependencies, so both teachers and education officials will be seriously unimpressed. What, BTW, gives you the greatest argument against Windows that can be ever made when introducing any new tools to educators. Unless the country is slated to become the next giant outsourced tech support farm, Windows user training is a microscopic part of the curriculum, and existing computer classes with desktops cover it completely. No one would buy a laptop per child just to enhance a small, unimportant piece of a large curriculum that as a whole has nearly nothing to do with computers in general and Windows in particular. However presenting a laptop as a tool that supports better methods for studying things that are already in the curriculum, a tool that is easy to adapt, that is not tied to some predefined commercial "educational" software made for a foreign school system, you can score major points on suitability when faced with education officials in countries that strongly support national curriculum. -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: View Source question
Yoshiki Ohshima wrote: > If there is any real operating system researchers around, they would > "raise eyebrows" when they hear the idea of letting the kids learn > Linux as *the* example. Remember the discussion between Linus > Torvalds and Andrew Tannenbaum, and Tannenbaum was right about Linux > has nothing great in regards to its technology. Linus was great at > forming the community by listening people, but its success wasn't > about its technology. (There are arguably better systems like > OpenBSD. And, it wasn't conceivable to actually do in that short > time, an OS-less system would have made more sense for the target > system; as you know, Ivan was thinking the possibility of "full Python > machine".) 1. It's very unlikely that kids will have any inclination to look at the kernel source. 2. Tannenbaum complained about Linux not being a microkernel. So far there is STILL no evidence that microkernels are better as a design -- certainly not if you look at the quality of operating systems implemented as microkernels. 3. Kernel code may not always look nice or straightforward (though I wouldn't use OpenBSD as an example of something better than Linux in that respect), however Unixlike systems' interface between kernel and userspace, and standard set of libc functions (more or less what POSIX is supposed to define) is at this point in history the greatest, unsurpassed achievement among all APIs made for any purpose. That includes all subsequent attempts to "improve" it in an incompatible way. Consistently designed system of file descriptors and operations on them, clear separation and mapping between userspace and kernel primitives, security tied to attributes of a very small set of objects are the reason why all open source systems that went anywhere, implement this interface, and not something else. Constant attempts to continue development of a system without using those principles are the reason why Windows requires such an enormous amount of effort for each version to be released. -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[sugar] Microsoft
>On a final note: > "Additionally, the Fedora, Debian and Ubuntu software environments run > on the XO-1, adding support for tens of thousands of free software > applications." > > I am terrified at the thought that the rest of this press release > might be anywhere near as disingenuous as this statement. No part of > it is actually untrue, but all of it is misleading. Hell, there has > yet to be a single build of the OLPC distro that is feature-complete > -- and I can tell you from personal experience that Debian, Fedora, > Slackware, and many other operating systems can *run* but aren't > *practical.* To clarify things, "Ubuntu-on-XO" project is basically three or four guys who don't know each other, releasing tarballs and installation instructions, and about half a dozen people on bulletin boards sharing scripts and configuration files. I happen to be among them (I prepared a Hardy/Xfce installation tarballs and made tweaks for GUI, configuration and Youtube-related script/packages), but I really don't deserve any significant credit for the minimal amount of work I have done, the amount of work is minimal, and there is no organization or coordination behind it. Ubuntu Sugar packages are a more significant step, though they aren't even related to XO hardware. I haven't even looked at the SD problem despite the fact that I recommended SD as the installation media (just made sure that power management does not kick in), and I am actually a kernel developer myself, so it's closer to my primary expertise than tweaking boot process, choosing the "right" init, repainting icons and resizing scrollbars. -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Marvell microkernel
Albert Cahalan wrote: > On Mon, May 5, 2008 at 3:26 AM, Alex Belits > <[EMAIL PROTECTED]> wrote: > >> If Marvell can release "tangled source" for ARM code that depends on >> proprietary microkernel, it would be an ordinary porting effort to make it >> work without that microkernel. > > Let go of that dream. Marvell is just giving excuses for > why they won't release the rest of the code. The true > reasons are not public, but likely: the code is a buggy > piece of crap that Marvell sees as being valuable IP. I don't know, I would expect this behavior from Broadcom but not Marvell. As for embarrassingly buggy pieces of crap, we already know that most of firmware is in this category, they are not going to surprise anyone. It also won't be the first situation when release of buggy source of the formerly closed "reference implementation" can lead to far superior open version. > That dream has already cost us dearly, and I think it > was intentional. People would have started work over > a year ago had they known how dishonest Marvell > would be. If this is the case, can anyone determine, what exactly we can get from Marvell -- chip data sheets, any other documentation, etc.? If we can't get it from Marvell, it can be derived by reverse engineering, but it will be nice to find out what they can provide. -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Marvell microkernel
Edward Cherlin wrote: > On Sun, May 4, 2008 at 10:20 PM, Alex Gibson <[EMAIL PROTECTED]> wrote: >> Edward Cherlin wrote: >> >>> How is everybody doing? and how is progress on the microkernel? >>> >>> Has anybody else gotten involved? >>> >>> Now that rms has actually switched to an XO, we ought to get on with this. >>> >>> Who has e-mail addresses for bobkeyes, palfrey, or ido? They listed >>> themselves on our Wiki page, but I don't see any way to contact them. >>> >> We (UTS) are no longer involved after we couldn't get access to the Marvell >> source code. > > You don't mean this source code, then? What have I missed? > > Driver source code: 8388 "libertas" driver from our kernel tree: > git://git.infradead.org/users/marcelo/libertas managed by Marcelo > Tosatti, discussion The driver source code (the only relevant source code that I am aware of being available) is a client to Marvell ARM code that runs on the chip and currently requires closed microkernel. The design of this chip places most of networking and hardware control functionality not into Linux driver but into ARM code, what is good from standpoint of efficient hardware use but allows entirely closed implementation despite open drivers on the Linux side. > Gabor, what happened to the effort you talked about in late 2006? > > http://lists.laptop.org/pipermail/devel/2006-December/003423.html > "...In parallel we are working with Marvell to release the 802.11s > source code under GPL. > > "Who is going to ravel out the 802.11s code from the tangled source ? > I'd help if needed." If Marvell can release "tangled source" for ARM code that depends on proprietary microkernel, it would be an ordinary porting effort to make it work without that microkernel. Most likely a large piece of microkernel's functionality is unused or unnecessary, so it's not even a matter of making or finding an exact equivalent of microkernel that this code uses now. I have seen embedded code running on no or little infrastructure, and there is no reason to expect that this particular adapter's hardware requires anything more than serving interrupts and performing DMA transfers -- the rest is wireless radio control and protocols implementation that is independent from any infrastructure. -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
