Python Megawidgets
___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Python Megawidgets on XO
Dear all, Can you kindly let me know how to install Python Mega Widgets on XO? Thanks a lot in advance, Sung-Hyuck p.s. Please ignore the previous empty e-mail. Sorry for that. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Quantum cryptography on the xo laptop (24C3)
Hey folks, crazy news: On Saturday 29.12.07, there was a successful 'entanglement based quantum key distribution' between two xo-laptops!! QKD is a quantum-cryptographic scheme to securely distribute correlated random numbers between the communicating parties. At the 24C3, we (sj and aaron, chris, tano from olpc-austria) met people from the National University of Singapore, which brought the hardware of a full working kit for entanglement based QKD over a free space channel. They got interested on the xo, started playing with 2 of the laptops, and finally had success exchangig the keys between two xo laptops. Read more here (with pics): http://www.olpcaustria.org/mediawiki/index.php/Quantum_Cryptography All the best 2008! - Chris ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: iwpriv (Was: OLPC News 2007-12-30)
On Mon, 2007-12-31 at 18:10 +, David Woodhouse wrote:
An interesting goal would be cleaning up CONFIG_OLPC so that
it could be enabled in stock kernels of standard Linux distros.
I actually see that as a prerequisite for getting the thing upstream.
And the first step along that path is to stop making it worse.
Let's see if we can repeat history. If experience with the libertas
driver is anything to go by, I predict that by starting to look at the
problem, I will provoke others into a generating a storm of conflicting
patches by attempting to do the same thing themselves¹.
So here's an untested patch to make the reboot fixups slightly more
generic, so that we can easily add our own 'fixup' for the XO in a
fashion which will actually be mergeable upstream.
Untested-but-otherwise-Signed-Off-By: David Woodhouse [EMAIL PROTECTED]
diff --git a/arch/x86/kernel/reboot_32.c b/arch/x86/kernel/reboot_32.c
index bb1a0f8..dedb1d8 100644
--- a/arch/x86/kernel/reboot_32.c
+++ b/arch/x86/kernel/reboot_32.c
@@ -332,9 +332,7 @@ static void native_machine_shutdown(void)
#endif
}
-void __attribute__((weak)) mach_reboot_fixups(void)
-{
-}
+void (*mach_reboot_fixup)(void);
static void native_machine_emergency_restart(void)
{
@@ -347,7 +345,8 @@ static void native_machine_emergency_restart(void)
/* rebooting needs to touch the page at absolute addr 0 */
*((unsigned short *)__va(0x472)) = reboot_mode;
for (;;) {
- mach_reboot_fixups(); /* for board specific fixups */
+ if (mach_reboot_fixup)
+ mach_reboot_fixup();
mach_reboot();
/* That didn't work - force a triple fault.. */
load_idt(no_idt);
diff --git a/arch/x86/kernel/reboot_fixups_32.c
b/arch/x86/kernel/reboot_fixups_32.c
index f452726..d9607a7 100644
--- a/arch/x86/kernel/reboot_fixups_32.c
+++ b/arch/x86/kernel/reboot_fixups_32.c
@@ -14,16 +14,18 @@
#include asm/msr.h
#include asm/geode.h
-static void cs5530a_warm_reset(struct pci_dev *dev)
+static pci_dev *cs5530a_pci_dev;
+
+static void cs5530a_warm_reset(void)
{
/* writing 1 to the reset control register, 0x44 causes the
cs5530a to perform a system warm reset */
- pci_write_config_byte(dev, 0x44, 0x1);
+ pci_write_config_byte(cs5530_pci_dev, 0x44, 0x1);
udelay(50); /* shouldn't get here but be safe and spin-a-while */
return;
}
-static void cs5536_warm_reset(struct pci_dev *dev)
+static void cs5536_warm_reset(void)
{
/* writing 1 to the LSB of this MSR causes a hard reset */
wrmsrl(MSR_DIVIL_SOFT_RESET, 1ULL);
@@ -48,24 +50,23 @@ static struct device_fixup fixups_table[] = {
* do return, we keep looking and then eventually fall back to the
* standard mach_reboot on return.
*/
-void mach_reboot_fixups(void)
+int mach_reboot_fixup_setup(void)
{
struct device_fixup *cur;
struct pci_dev *dev;
int i;
- /* we can be called from sysrq-B code. In such a case it is
-* prohibited to dig PCI */
- if (in_interrupt())
- return;
-
for (i=0; i ARRAY_SIZE(fixups_table); i++) {
cur = (fixups_table[i]);
dev = pci_get_device(cur-vendor, cur-device, NULL);
if (!dev)
continue;
- cur-reboot_fixup(dev);
+ cs5530a_pci_dev = dev;
+ mach_reboot_fixup = cur-reboot_fixup;
}
+ return 0;
}
+subsys_initcall(mach_reboot_fixup_setup);
+
diff --git a/include/asm-x86/reboot_fixups.h b/include/asm-x86/reboot_fixups.h
index 0cb7d87..4f79001 100644
--- a/include/asm-x86/reboot_fixups.h
+++ b/include/asm-x86/reboot_fixups.h
@@ -1,6 +1,6 @@
#ifndef _LINUX_REBOOT_FIXUPS_H
#define _LINUX_REBOOT_FIXUPS_H
-extern void mach_reboot_fixups(void);
+extern void (*mach_reboot_fixup)(void);
#endif /* _LINUX_REBOOT_FIXUPS_H */
--
dwmw2
¹ Only this time I don't actually plan to follow through; I'm relying on
the interference
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
[Tele]Health Update
There has, in the past few months, been a surge of interest in health and telehealth applications for the XO. My own efforts have been focused on telehealth hardware and software intended for use in scenarios where medical facilities are available but man hours to manually screen individuals is not. This is a scenario faced in many large third-world cities in addition to refuge camps. Codyl and Dirakx have been assisting; Codyl handling the micro-controller part, Dirakx working with a Columbian team to develop an EKG. I have designed a Pulse Oximeter based heavily on a communications photodiode instrumentation amplifier. I have started prototyping over Christmas break. I am working with Dirakx and Dr. Dhurjaty to design and prototype an EKG unit providing valuable diagnostic information about Arrythmia. Both of these devices will also provide valuable pedagogical resources. I have designed a server-client infrastructure of the following form for the THPM activity(telehealth parameterized activity): A GTK+/PyGTK based gui feeds information into a program which creates an XML document via PXTL XML templating. This XML file is uploaded to a server running an httpd and ftpd using the ftplib python module, along with images in a .jpg format and waveforms in a .wav format. The program creates a folder on the server of the following form /www /username /time /health.xml /image_of_affected_bodypart1.jpg /image_of_affected_bodypart2.jpg /pulseox.wav /stethescope_and_audio.wav /ekg.wav /health.css From this structure, a doctor can access a webpage from the url format: http://server/username/time/health.xml The XML file will be rendered by a CSS file in the root web directory. The THM(TeleHealth Module) activity will use code similar to the measure code to record and then display waveforms inputted via a USB Analog to Digital Converter. In addition to all this, there has been a movement to convert the .pdf Hesperian foundation work *Where There is No Doctor* into [x]html. Pascals has been heading up this work. Anyone interested in contributing, feel free to contact me via any of the below means. Many thanks, -- Ian Daniher [EMAIL PROTECTED] Skype : it.daniher irc.freenode.com: DyDisMe ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: iwpriv (Was: OLPC News 2007-12-30)
David Woodhouse wrote: So here's an untested patch to make the reboot fixups slightly more generic, so that we can easily add our own 'fixup' for the XO in a fashion which will actually be mergeable upstream. It would be slightly nicer and generic if we had void (*mach_reboot_fixup)(void *arg); void *mach_reboot_fixup_arg; rather than the cs5530a_pci_dev global. But anyway, Untested-but-otherwise-Signed-Off-By: David Woodhouse [EMAIL PROTECTED] Untested-but-otherwise-Acked-By: Bernardo Innocenti [EMAIL PROTECTED] -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Kernel configuration options
I'm not sure about some of the kernel configuration options. A few minor things stick out in my mind; I don't know the rationale behind some of these things and am curious about developer decisions and thoughts on how to build the kernel. * CONFIG_NO_HZ + CONFIG_HZ=100? * SLAB vs SLUB * Some debugging stuff * More debugging stuff * Building stuff as modules First off I noticed CONFIG_NO_HZ=y and CONFIG_HZ=100; is this a quirk of the kernel's general configuration? As I understand, these options should be mutually exclusive because CONFIG_HZ is a parameter of a scheduler using a different methodology than CONFIG_NO_HZ... Another thing is I noticed CONFIG_SLAB=y, but the SLUB allocator is supposed to be a faster generic replacement for SLAB.[1] Is there a reason the XO doesn't use it? I'm also noticing some things like KALLSYMS and BUG(), BSD process accounting, and the like. KALLSYMS, BUG(), and printk() are useful; on a true embedded device I'd say remove 'em but I can't justify it here... BSD process accounting and auditd support though? In the same line, a lot of debugging options are in use. I'm using Build 653, I guess it may be a developer's build and thus there's a lot of debugging stuff; but in the final should things like CONFIG_PROFILING , CONFIG_KPROBES, CONFIG_DEBUG_FS, CONFIG_UNUSED_SYMBOLS, CONFIG_SCHEDSTATS, CONFIG_TIMER_STATS, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SPINLOCK ... be removed? Finally, I'm noticing a lot of stuff can be built as modules, but is built in. Networking in its entirety; sound drivers; mouse; and USB (the mouse looks like it's PS2) can be loaded by HAL and UDEV, but this will increase boot time (then again, HAL apparently needs to be fixed anyway[2], so this could be encouraging?). More interesting to me however is that EXT2, EXT3, Joliet, ZISOFS, RAMFS, NFS, and possibly PROMFS because I don't think JFFS2 depends on it BUT I'm not sure if it's used at some point before it can be loaded as a module. [1] http://lwn.net/Articles/229984/ [2] http://lwn.net/Articles/192214/ -- Bring back the Firefox plushy! http://digg.com/linux_unix/Is_the_Firefox_plush_gone_for_good https://bugzilla.mozilla.org/show_bug.cgi?id=322367 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
I can't speak for the OLPC kernel folks, but here's a few thoughts: First off I noticed CONFIG_NO_HZ=y and CONFIG_HZ=100; is this a quirk of the kernel's general configuration? As I understand, these options should be mutually exclusive because CONFIG_HZ is a parameter of a scheduler using a different methodology than CONFIG_NO_HZ... In the current dyntick scheme the regular clock interrupt still happens when the processor is busy - it's only disabled when things go idle. So you still need to set HZ to something. It also sets the resolution of much of the timekeeping within the kernel. Another thing is I noticed CONFIG_SLAB=y, but the SLUB allocator is supposed to be a faster generic replacement for SLAB.[1] Is there a reason the XO doesn't use it? I don't know why that decision was made, but SLUB is still new and still getting a few things shaken out of it. Using slab for the currently-shipped system makes sense to me. jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: qemu and the file system and development
Steve Lewis wrote: I have gotten sugar running under windows with QEMU - no I have lots of questions 1) If I make changes in the emulated system are those changes remembered between runs? Yes. 2) Can I have the emulator point at a part of the windows file system - allowing my tools to work on data to be used by the system Easiest way is using samba. If you were using Linux as a host, I'd recommend nfs (fast) or sshfs (easier to setup). If you manage to get Samba to work on the laptop, please add a wiki page describing the procedure you followed. 3) How do I move changes I made on the XO to the emultator 4) How can I move changes I make in the emulator to the XO scp and sftp are the easiest way. On windows, try the putty suite of ssh programs. Is there a way to hook an external ide to the image running in QEMU Just share the source (and binary) directory with any network filesystem. You can debug C application remotely with gdbserver. Python has its own debugger. For development, I usually just ssh into the laptop as root from my desktop, so I have fast scrolling, cut paste, etc. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
John Richard Moser wrote: I'm also noticing some things like KALLSYMS and BUG(), BSD process accounting, and the like. KALLSYMS, BUG(), and printk() are useful; on a true embedded device I'd say remove 'em but I can't justify it here... BSD process accounting and auditd support though? Yeah ... I run stuff like that in *my* kernels, but I'm a kernel geek. Does that stuff need to be in a machine in a village school in Rwanda? P.S.: I do know a Red Hat geek in Nigeria. :) In the same line, a lot of debugging options are in use. I'm using Build 653, I guess it may be a developer's build and thus there's a lot of debugging stuff; but in the final should things like CONFIG_PROFILING , CONFIG_KPROBES, CONFIG_DEBUG_FS, CONFIG_UNUSED_SYMBOLS, CONFIG_SCHEDSTATS, CONFIG_TIMER_STATS, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SPINLOCK ... be removed? I think I agree with you here with the possible exception of CONFIG_PROFILING aka oprofile support. Finally, I'm noticing a lot of stuff can be built as modules, but is built in. Networking in its entirety; sound drivers; mouse; and USB (the mouse looks like it's PS2) can be loaded by HAL and UDEV, but this will increase boot time (then again, HAL apparently needs to be fixed anyway[2], so this could be encouraging?). More interesting to me however is that EXT2, EXT3, Joliet, ZISOFS, RAMFS, NFS, and possibly PROMFS because I don't think JFFS2 depends on it BUT I'm not sure if it's used at some point before it can be loaded as a module. I'd keep as much as possible that's XO-specific and *always* going to be loaded built in. You're always going to need sound, mouse and keyboard, wireless and video, and I'd keep the core USB stuff built in as well, since that's really the only way to talk to the machine besides wireless. But the rest of it should be built as modules. The filesystems should be there (as modules). The XO is going to be talking to school servers, and there's no point in ruling out NFS, Samba, plugging in an external USB DVD reader/writer, etc. Again, the question is, would a village in Rwanda format a USB stick ext3? :) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Tele]Health Update
On Jan 1, 2008 9:36 AM, Ian Daniher [EMAIL PROTECTED] wrote: There has, in the past few months, been a surge of interest in health and telehealth applications for the XO. Glad to hear it. I have been talking up the idea for several years but evidently not to the right people. %-[ There is a telemedicine kit from India for about $200, and there are other possibilities. I have been encouraged by developments in blood chemistry measurements that do not require a needle stick. The first such product is likely to be a diabetic blood sugar meter, but the process applies to any small molecule with a distinctive spectrum. I also have friends in the medical software business. There is a Free Software implementation of the M language and the entire US Veterans Administration/DoD hospital software system for medical records, administration, pharmacy, and much more. My own efforts have been focused on telehealth hardware and software intended for use in scenarios where medical facilities are available but man hours to manually screen individuals is not. This is a scenario faced in many large third-world cities in addition to refuge camps. Codyl and Dirakx have been assisting; Codyl handling the micro-controller part, Dirakx working with a Columbian team to develop an EKG. I have designed a Pulse Oximeter based heavily on a communications photodiode instrumentation amplifier. I have started prototyping over Christmas break. I am working with Dirakx and Dr. Dhurjaty to design and prototype an EKG unit providing valuable diagnostic information about Arrythmia. Both of these devices will also provide valuable pedagogical resources. I have designed a server-client infrastructure of the following form for the THPM activity(telehealth parameterized activity): A GTK+/PyGTK based gui feeds information into a program which creates an XML document via PXTL XML templating. This XML file is uploaded to a server running an httpd and ftpd using the ftplib python module, along with images in a .jpg format and waveforms in a .wav format. The program creates a folder on the server of the following form /www /username /time /health.xml /image_of_affected_bodypart1.jpg /image_of_affected_bodypart2.jpg /pulseox.wav /stethescope_and_audio.wav /ekg.wav /health.css From this structure, a doctor can access a webpage from the url format: http://server/username/time/health.xml The XML file will be rendered by a CSS file in the root web directory. The THM(TeleHealth Module) activity will use code similar to the measure code to record and then display waveforms inputted via a USB Analog to Digital Converter. In addition to all this, there has been a movement to convert the .pdf Hesperian foundation work Where There is No Doctor into [x]html. Pascals has been heading up this work. Anyone interested in contributing, feel free to contact me via any of the below means. Many thanks, -- Ian Daniher [EMAIL PROTECTED] Skype : it.daniher irc.freenode.com: DyDisMe ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Edward Cherlin Earth Treasury: End Poverty at a Profit http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Peripherals] [Tele]Health Update
Hi all, As Ian said i'm working in a EKG prototype with the assistance of a professor and alumni of my uni, The process has been stoped due to intersemestral vacations but we have a working prototype, although we still need a lot of improvements. So i guess in two weeks or so we will continue with the development. I hope soon, i can upload the footprint of the prototype, and all the related info. Cheers! On Jan 1, 2008 12:36 PM, Ian Daniher [EMAIL PROTECTED] wrote: There has, in the past few months, been a surge of interest in health and telehealth applications for the XO. My own efforts have been focused on telehealth hardware and software intended for use in scenarios where medical facilities are available but man hours to manually screen individuals is not. This is a scenario faced in many large third-world cities in addition to refuge camps. Codyl and Dirakx have been assisting; Codyl handling the micro-controller part, Dirakx working with a Columbian team to develop an EKG. I have designed a Pulse Oximeter based heavily on a communications photodiode instrumentation amplifier. I have started prototyping over Christmas break. I am working with Dirakx and Dr. Dhurjaty to design and prototype an EKG unit providing valuable diagnostic information about Arrythmia. Both of these devices will also provide valuable pedagogical resources. I have designed a server-client infrastructure of the following form for the THPM activity(telehealth parameterized activity): A GTK+/PyGTK based gui feeds information into a program which creates an XML document via PXTL XML templating. This XML file is uploaded to a server running an httpd and ftpd using the ftplib python module, along with images in a .jpg format and waveforms in a .wav format. The program creates a folder on the server of the following form /www /username /time /health.xml /image_of_affected_bodypart1.jpg /image_of_affected_bodypart2.jpg /pulseox.wav /stethescope_and_audio.wav /ekg.wav /health.css From this structure, a doctor can access a webpage from the url format: http://server/username/time/health.xml The XML file will be rendered by a CSS file in the root web directory. The THM(TeleHealth Module) activity will use code similar to the measure code to record and then display waveforms inputted via a USB Analog to Digital Converter. In addition to all this, there has been a movement to convert the .pdf Hesperian foundation work *Where There is No Doctor* into [x]html. Pascals has been heading up this work. Anyone interested in contributing, feel free to contact me via any of the below means. Many thanks, -- Ian Daniher [EMAIL PROTECTED] Skype : it.daniher irc.freenode.com: DyDisMe ___ Peripherals mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/peripherals -- Rafael Enrique Ortiz Guerrero One Laptop Per Child [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Peripherals] [Tele]Health Update
Hi all, Just an update: Pascals has an 'alpha' version of Hesperian WTND Chapter one up online here http://pascal.scheffers.net/Outputs/chapter%201.html. This is to be compared to the PDF version herehttp://www.hesperian.org/assets/wtnd/WTND_Chapter_1_pdf.php . Best wishes, Ian On Jan 1, 2008 4:18 PM, Rafael Enrique Ortiz Guerrero [EMAIL PROTECTED] wrote: Hi all, As Ian said i'm working in a EKG prototype with the assistance of a professor and alumni of my uni, The process has been stoped due to intersemestral vacations but we have a working prototype, although we still need a lot of improvements. So i guess in two weeks or so we will continue with the development. I hope soon, i can upload the footprint of the prototype, and all the related info. Cheers! On Jan 1, 2008 12:36 PM, Ian Daniher [EMAIL PROTECTED] wrote: There has, in the past few months, been a surge of interest in health and telehealth applications for the XO. My own efforts have been focused on telehealth hardware and software intended for use in scenarios where medical facilities are available but man hours to manually screen individuals is not. This is a scenario faced in many large third-world cities in addition to refuge camps. Codyl and Dirakx have been assisting; Codyl handling the micro-controller part, Dirakx working with a Columbian team to develop an EKG. I have designed a Pulse Oximeter based heavily on a communications photodiode instrumentation amplifier. I have started prototyping over Christmas break. I am working with Dirakx and Dr. Dhurjaty to design and prototype an EKG unit providing valuable diagnostic information about Arrythmia. Both of these devices will also provide valuable pedagogical resources. I have designed a server-client infrastructure of the following form for the THPM activity(telehealth parameterized activity): A GTK+/PyGTK based gui feeds information into a program which creates an XML document via PXTL XML templating. This XML file is uploaded to a server running an httpd and ftpd using the ftplib python module, along with images in a .jpg format and waveforms in a .wav format. The program creates a folder on the server of the following form /www /username /time /health.xml /image_of_affected_bodypart1.jpg /image_of_affected_bodypart2.jpg /pulseox.wav /stethescope_and_audio.wav /ekg.wav /health.css From this structure, a doctor can access a webpage from the url format: http://server/username/time/health.xml The XML file will be rendered by a CSS file in the root web directory. The THM(TeleHealth Module) activity will use code similar to the measure code to record and then display waveforms inputted via a USB Analog to Digital Converter. In addition to all this, there has been a movement to convert the .pdf Hesperian foundation work *Where There is No Doctor* into [x]html. Pascals has been heading up this work. Anyone interested in contributing, feel free to contact me via any of the below means. Many thanks, -- Ian Daniher [EMAIL PROTECTED] Skype : it.daniher irc.freenode.com: DyDisMe ___ Peripherals mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/peripherals -- Rafael Enrique Ortiz Guerrero One Laptop Per Child [EMAIL PROTECTED] -- Ian Daniher [EMAIL PROTECTED] Skype : it.daniher irc.freenode.com: DyDisMe ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
From a security standpoint, there is an advantage to building in everything. The main kernel is verified with a crypto signature before it is executed. Loading a module without first verifying a similarly-strong signature weakens the security. Modules are a good idea for kernels that are intended to run on a wide variety of hardware. I am in favor of treating XO like an appliance and making the kernel as monolithic as possible. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Mitch Bradley wrote: From a security standpoint, there is an advantage to building in everything. The main kernel is verified with a crypto signature before it is executed. Loading a module without first verifying a similarly-strong signature weakens the security. Modules are a good idea for kernels that are intended to run on a wide variety of hardware. I am in favor of treating XO like an appliance and making the kernel as monolithic as possible. I'm not familiar with the security stuff in general or this case in particular. But I think the trend in the Linux community has been towards more flexibility, moving stuff from kernel space to user space, etc. Then again, since the *hardware* is soldered onto the mainboard and can't be easily expanded, why shouldn't the *kernel* be just as inflexible? ;) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Devel Digest, Vol 23, Issue 2
There is a telemedicine kit from India for about $200, and there are other possibilities. I have been encouraged by developments in blood chemistry measurements that do not require a needle stick. The first such product is likely to be a diabetic blood sugar meter, but the process applies to any small molecule with a distinctive spectrum. I also have friends in the medical software business. There is a Free Software implementation of the M language and the entire US Veterans Administration/DoD hospital software system for medical records, administration, pharmacy, and much more. Glad to hear of these. Any one of these things can be developed/run around/on the XO ? thanks Arjun -- Arjun Sarwal ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Updates API documentation for everything.
On Dec 30, 2007 10:20 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: I have run the python documentation tool 'epydoc' on the contents of the joyride-1477 release. The results are here: http://dev.laptop.org/~cscott/joyride-1477-api/ Thanks. I was wishing for that. Can you do the other major builds also? I am running 653, and I keep hearing about Update.1. Does anybody know of a documentation tool for Open Firmware, or for FORTH more generally? Exploring using 'words' and 'see' This is probably the most up-to-date documentation available now for Sugar, the update and contents tools, rainbow, etc. I plan to integrate this into the joyride build process, so that there are always current API docs available. Thank you, thank you. When you can create a URL that will always go to the latest version, please add it to the Wiki. Comments welcome! And those of you who have not adequately documented your code, please do. Module-level comments in particular are very helpful, and often missing. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel http://www.documentia.ca/lies.htm Biggest Lies Heard by Technical Writers * You should have a fully-functional product in your hands in plenty of time to complete your document. * The product's so intuitive, it practically writes the manual itself. * You won't be thought of as a nuisance by the SME's. They accept that you're a peer and respect that you have a job to do. * I'd make that more abstract. We'll make sure you have everything you need to get the job done. * As the tech writer at our company, you will have full, unrestricted access to the devolopment team's time and resources. etc. -- Edward Cherlin Earth Treasury: End Poverty at a Profit http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Updates API documentation for everything.
Sorry. It got away from me. On Jan 1, 2008 2:11 PM, Edward Cherlin [EMAIL PROTECTED] wrote: On Dec 30, 2007 10:20 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: I have run the python documentation tool 'epydoc' on the contents of the joyride-1477 release. The results are here: http://dev.laptop.org/~cscott/joyride-1477-api/ Thanks. I was wishing for that. Can you do the other major builds also? I am running 653, and I keep hearing about Update.1. Does anybody know of a documentation tool for Open Firmware, or for FORTH more generally? Exploring using 'words' and 'see' is fun up to a point if you're learning FORTH, but really doesn't cut it for supporting documentation. And what about Smalltalk/Etoys? This is probably the most up-to-date documentation available now for Sugar, the update and contents tools, rainbow, etc. I plan to integrate this into the joyride build process, so that there are always current API docs available. Thank you, thank you. When you can create a URL that will always go to the latest version, please add it to the Wiki. Comments welcome! And those of you who have not adequately documented your code, please do. Module-level comments in particular are very helpful, and often missing. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel http://www.documentia.ca/lies.htm Biggest Lies Heard by Technical Writers * You should have a fully-functional product in your hands in plenty of time to complete your document. * The product's so intuitive, it practically writes the manual itself. * You won't be thought of as a nuisance by the SME's. They accept that you're a peer and respect that you have a job to do. * I'd make that more abstract. We'll make sure you have everything you need to get the job done. * As the tech writer at our company, you will have full, unrestricted access to the devolopment team's time and resources. etc. -- Edward Cherlin Earth Treasury: End Poverty at a Profit http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay -- Edward Cherlin Earth Treasury: End Poverty at a Profit http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Mitch Bradley wrote: From a security standpoint, there is an advantage to building in everything. The main kernel is verified with a crypto signature before it is executed. Loading a module without first verifying a similarly-strong signature weakens the security. Modules are a good idea for kernels that are intended to run on a wide variety of hardware. I am in favor of treating XO like an appliance and making the kernel as monolithic as possible. Uh-oh... Does our security system really depend on this? Reducing the number of modules is not going to help, because you only need to load a single module to tap into the kernel. Building everything statically and disabling module loading is also not an option if you want half decent support for USB devices. Note that USB also brings in SCSI, DVB, and a lot more. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
John Richard Moser wrote: I'm not sure about some of the kernel configuration options. A few minor things stick out in my mind; I don't know the rationale behind some of these things and am curious about developer decisions and thoughts on how to build the kernel. * CONFIG_NO_HZ + CONFIG_HZ=100? * SLAB vs SLUB * Some debugging stuff * More debugging stuff * Building stuff as modules Please, build a kernel with the changes you consider useful, and make it available somewhere, along with your proposed config patch. Please make sure that the resulting kernel also still works on QEMU and VMware. Extra bonus points if you can give hard numbers on memory saving and performance gains. As a super-quick-and-dirty test, note that /home/olpc/.boot_time records the time it takes to get from kernel startup to the X session. We can expect that time to be slighly influenced by your improvements because booting exercises several kernel subsystems, including vfs, slab, forks and mmaps. First off I noticed CONFIG_NO_HZ=y and CONFIG_HZ=100; is this a quirk of the kernel's general configuration? As I understand, these options should be mutually exclusive because CONFIG_HZ is a parameter of a scheduler using a different methodology than CONFIG_NO_HZ... Probably a (harmless) leftover of editing the .config manually. Another thing is I noticed CONFIG_SLAB=y, but the SLUB allocator is supposed to be a faster generic replacement for SLAB.[1] Is there a reason the XO doesn't use it? Don't expect too much out of it: http://lwn.net/Articles/261868/ But I still think we should try it and maybe use it. I'm also noticing some things like KALLSYMS and BUG(), BSD process accounting, and the like. KALLSYMS, BUG(), and printk() are useful; on a true embedded device I'd say remove 'em but I can't justify it here... BSD process accounting and auditd support though? I'd keep the debug symbols (which shouldn't cost any memory at runtime). In the same line, a lot of debugging options are in use. I'm using Build 653, I guess it may be a developer's build and thus there's a lot of debugging stuff; but in the final should things like CONFIG_PROFILING , CONFIG_KPROBES, CONFIG_DEBUG_FS, CONFIG_UNUSED_SYMBOLS, CONFIG_SCHEDSTATS, CONFIG_TIMER_STATS, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SPINLOCK ... be removed? I side with M.Edward on keeping oprofile support, which does not slowdown the system and can be built as a module. Finally, I'm noticing a lot of stuff can be built as modules, but is built in. Go for it! But please note that we're using a weird initrd that doesn't contain modules (or maybe does, but cannot easily be regenerated along with the kernel). Because of this, I think all the modules required for booting off jffs2 and ext3 need to be linked in :-( -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Updates API documentation for everything.
Edward Cherlin wrote: Does anybody know of a documentation tool for Open Firmware, or for FORTH more generally? Exploring using 'words' and 'see' Are you looking for automated documentation generation, or FORTH coding and documentation standards? I don't know about the former, but there is a well-established set of the latter, and given adherence, I'm sure the former is eminently possible. The FORTH community is fairly small (relative to, say, Python), and as a result, most FORTH programmers don't have much trouble reading the code of other FORTH programmers. But I don't know about outsiders coming to FORTH from more traditional languages. :) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Updates API documentation for everything.
From: Edward Cherlin [EMAIL PROTECTED] And what about Smalltalk/Etoys? Not sure what level of doc you're seeking. If I misunderstood you, I apologize. Smalltalk's libraries are to a certain extent self-documenting in its browser, which is good because they vary depending on whatever you've synced from the central repositories. For Squeak overall, we have http://www.squeakbyexample.org. For how-to Etoys (the media/animation layer), I'm pretty impressed so far by the series of videos on http://www.waveplace.com/movies/ (speaking as somebody who doesn't care for non-written doc as a rule). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Updates API documentation for everything.
Edward Cherlin wrote: Does anybody know of a documentation tool for Open Firmware, or for FORTH more generally? Exploring using 'words' and 'see' is fun up to a point if you're learning FORTH, but really doesn't cut it for supporting documentation. I presume that you have seen the tutorials at http://wiki.laptop.org/go/Forth_Lessons The basic Open Firmware level is reasonably well documented - http://docs.sun.com/app/docs/doc/805-4436 http://firmworks.com/QuickRef.html The OLPC-specific stuff could certainly use some additional documentation. The source code for the OLPC-specific stuff has some amount of internal documentation that could be extracted. Each source file has a purpose comment at the top of the file, and many of the individual word definitions are preceded by a brief description. For example, the file cpu/x86/pc/olpc.fth begins with: purpose: Determine the board revision based on hardware and EC info and that file defines the word model-name$ as follows: \ Constructs a string like B4 or preB4 or postB4 : model-name$ ( -- model$ ) Many, but certainly not all, of the words that can plausibly be used interactively have brief description strings like that. Some words don't have brief descriptions in the source, and probably never will have them, based on the clarity of their names . For example, for the word bios-checksum-bad? ( -- flag ), I didn't feel compelled to write \ Returns true if the BIOS checksum is bad. The various xxx@ and xxx! words fall into that category, once you know the general pattern of @ and !. But even so, it would be nice to have a compendium of those words with English descriptions for easy reference. I'm not a big fan of automated documentation tools. They can help with the mechanics of extracting documentation strings from source code, but in my experience, such documentation is only marginally useful. The really hard part of understanding how something works is the contextual stuff - the circumstances under which it is appropriate to call a given function, how it fits together with related stuff, etc. Phrases are more enlightening than individual words. Automated documentation extraction tends to describe individual trees, leaving you wondering about the overall shape of the forest. Projects that are set up for auto doc tools tend to have long structured comment blocks before every function. The individual fields are often extremely boring - like Outputs: none, and the overall size of the comment block takes up so much screen real estate that the actual code is lost among the boilerplate. Going back to the bios-checksum-bad? ( -- flag ) example, the usual tendency would be to say something obviously correct, and entirely pointless, like Returns a boolean flag that is true if the BIOS checksum is bad. What really should be said is something like: Conventional PC BIOSes checksum the CMOS RAM between indices 0x10 and 0x2d inclusive, storing the arithmetic sum as a 2-byte big-endian integer at indices 0x2e and 0x2f. bios-checksum-bad? tests that checksum. It is an implementation factor of init-bios-cmos, which ensures that said checksum is correct, fixing the checksum by zeroing that entire area if not. But of course people rarely write documentation that complete, for any number of reasons. That said, I really need to go through all the new OLPC code and at least add brief descriptions for all the top-level words. Meanwhile, if anyone wants to look at the source code, the OLPC-specific bits are mostly collected in a few directories, primarily cpu/x86/build/olpc/ and dev/olpc/* The source tree is at http://openbios.org/Open_Firmware ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Packaging and Hello World Tutorial
I was trying a modification of the Hello World tutorial to package an application with a bunch of additional files (essentially the python acts as a launcher at the moment). In any case, when I follow the hello world tutorial instructions to create the MANIFEST and run setup.py, it complains about not being able to find the base component of the path as it starts to process the MANIFEST list as if its 'cwd' is the wrong directory. When I replace the step which builds the MANIFEST from the find command with a much more simple find command (find ./ MANIFEST), things seem to work, but it really doesn't like sub-directories (particularly empty ones). So - what's the suggested path here? Should I just manually create the package and zip it externally? Is there some easier path to what I'm trying to accomplish? -eric ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Uniting the community's infrastructure
Hi all! From now on, the channel #olpc-groups is open with the ambition to connect local communities from everywhere! I can imagine a lot of potential for collaborations, projects, problem solving and not-reinventing-the-wheel :) ! SJ and I have talked about the current status of the irc-infrastructure for the communities, and had some ideas for the future. Basically, 1. many of the local channels are inactive 2. we have had no channel to cross-connect communities 3. the channel #olpc-europe developed from the ccc 4. the whole olpc project is gaining momentum = 5. the logical next step would be a united communities-channel to focus our common effort! We could basically connect via #olpc-groups on a global basis, and use #olpc-europe/asia/africa/... for regional discussions. The same idea could apply to some of the mailing-lists. We can basically use the grassroots list (http://lists.laptop.org/listinfo/grassroots)! Please post feedback to [EMAIL PROTECTED] I wish you all an interesting and successful year 2008! - chris (olpc austria) ... _sj| crazy: there are no active country channels _sj| but very active community members :) we just need a place to discuss self-organization, regional meetups, a few infrastructure things (which are the same around the world) kikka a virtual place? _sj| well, here I'm talking about a single irc chan... kikka Ah, okay. crazy-chris _sj| you're right, the country channels are not used _sj| crazy: start with one #olpc-groups, merge existing country chans until there's a lot of focused traffic for one _sj| and keep separate channels for open discussion by language _sj| #olpc can split into #olpc-lang when it gets too busy; #olpc-groups can split into #olpc-region when it gets too busy. crazy-chris _sj|: okay, that sounds very good. _sj| but, none of the olpc chans are too busy yet :) crazy-chris heh, yeah crazy-chris will change thought :) _sj| even #olpc and -help are pretty quiet _sj| yeah crazy-chris the contributors program ... crazy-chris i think to merge the channels is the way to go. i'll get working on that. _sj| chris: thank you ... ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Uniting the community's infrastructure
Chris Hager wrote: Hi all! From now on, the channel #olpc-groups is open with the ambition to connect local communities from everywhere! I can imagine a lot of potential for collaborations, projects, problem solving and not-reinventing-the-wheel :) ! SJ and I have talked about the current status of the irc-infrastructure for the communities, and had some ideas for the future. Basically, 1. many of the local channels are inactive 2. we have had no channel to cross-connect communities 3. the channel #olpc-europe developed from the ccc 4. the whole olpc project is gaining momentum = 5. the logical next step would be a united communities-channel to focus our common effort! We could basically connect via #olpc-groups on a global basis, and use #olpc-europe/asia/africa/... for regional discussions. The same idea could apply to some of the mailing-lists. We can basically use the grassroots list (http://lists.laptop.org/listinfo/grassroots)! Please post feedback to [EMAIL PROTECTED] I wish you all an interesting and successful year 2008! - chris (olpc austria) Well, like a lot of the Internet and life in general, things tend to self-organize. I've started a Google group for Portland Oregon XO owners, and I'm personally on quite a few of the other mailing lists. In any event, I'm not sure it's time yet for any consolidation, either on mailing lists/Google Groups or in IRC. I think the best we should hope for at this point is to ask everyone on IRC to use the characters olpc in naming channels. That way, the IRC client channel listers can find them. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Bernardo Innocenti wrote: John Richard Moser wrote: I'm not sure about some of the kernel configuration options. A few minor things stick out in my mind; I don't know the rationale behind some of these things and am curious about developer decisions and thoughts on how to build the kernel. * CONFIG_NO_HZ + CONFIG_HZ=100? * SLAB vs SLUB * Some debugging stuff * More debugging stuff * Building stuff as modules Please, build a kernel with the changes you consider useful, and make it available somewhere, along with your proposed config patch. Please make sure that the resulting kernel also still works on QEMU and VMware. The base hardware drivers built in supports qemu and vmware? Looks like I gotta read up on the wiki about how to rebuild the kernels (again). It seems I can alter Grub to do what I want afterwards though. (Do I need a developer's key or smth?) Extra bonus points if you can give hard numbers on memory saving and performance gains. Black art ;) As a super-quick-and-dirty test, note that /home/olpc/.boot_time records the time it takes to get from kernel startup to the X session. We can expect that time to be slighly influenced by your improvements because booting exercises several kernel subsystems, including vfs, slab, forks and mmaps. Interesting! I didn't know this. Boot chart was pulled out for something else that I don't know how to use yet as well. First off I noticed CONFIG_NO_HZ=y and CONFIG_HZ=100; is this a quirk of the kernel's general configuration? As I understand, these options should be mutually exclusive because CONFIG_HZ is a parameter of a scheduler using a different methodology than CONFIG_NO_HZ... Probably a (harmless) leftover of editing the .config manually. Another thing is I noticed CONFIG_SLAB=y, but the SLUB allocator is supposed to be a faster generic replacement for SLAB.[1] Is there a reason the XO doesn't use it? Don't expect too much out of it: http://lwn.net/Articles/261868/ Point taken. But I still think we should try it and maybe use it. I'm also noticing some things like KALLSYMS and BUG(), BSD process accounting, and the like. KALLSYMS, BUG(), and printk() are useful; on a true embedded device I'd say remove 'em but I can't justify it here... BSD process accounting and auditd support though? I'd keep the debug symbols (which shouldn't cost any memory at runtime). Possibly not. The kernel runs inside one giant huge page doesn't it? 4MiB read-write-execute... In the same line, a lot of debugging options are in use. I'm using Build 653, I guess it may be a developer's build and thus there's a lot of debugging stuff; but in the final should things like CONFIG_PROFILING , CONFIG_KPROBES, CONFIG_DEBUG_FS, CONFIG_UNUSED_SYMBOLS, CONFIG_SCHEDSTATS, CONFIG_TIMER_STATS, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SPINLOCK ... be removed? I side with M.Edward on keeping oprofile support, which does not slowdown the system and can be built as a module. Finally, I'm noticing a lot of stuff can be built as modules, but is built in. Go for it! But please note that we're using a weird initrd that doesn't contain modules (or maybe does, but cannot easily be regenerated along with the kernel). Because of this, I think all the modules required for booting off jffs2 and ext3 need to be linked in :-( I think you can omit booting off ext3 for the final product. There is load-time consideration to be made about loading everything as modules (camera, USB, mouse, all of networking, sound, etc) and leaving the essentials (flash, display, keyboard, jffs2). Even if you leave networking and all the 100%-always-loaded modules compiled in, however, there's no need for things like 30 types of file systems. I'd personally leave out ipv4 and ipv6 and just load them at boot time; I'd rather not have ipv6 loaded right now, and ipv6 infrastructures should run without ipv4 (some apps will probably complain about no 127.0.0.1...); but this is just nitpicking. Really I like a tiny core kernel and a bunch of modules but as I said, increases the time needed to boot. -- Bring back the Firefox plushy! http://digg.com/linux_unix/Is_the_Firefox_plush_gone_for_good https://bugzilla.mozilla.org/show_bug.cgi?id=322367 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Mitch Bradley wrote: From a security standpoint, there is an advantage to building in everything. The main kernel is verified with a crypto signature before it is executed. Loading a module without first verifying a similarly-strong signature weakens the security. Loadable kernel modules are enabled in the config. This argument is moot. You can sign modules, RHEL supports this by default and has a boot option for it. More interesting, some cute hacks have been done before to get write access to the kernel through /dev/(k)mem, evading the protection of kernels not supporting modules. This is of course fixable. Modules are a good idea for kernels that are intended to run on a wide variety of hardware. I am in favor of treating XO like an appliance and making the kernel as monolithic as possible. I don't favor loading in modules for Joliet and other CD-ROM stuff, for RAMFS (which shouldn't be used anyway, use TMPFS), ROMFS (is this even used?), NTFS, ext2, ext3, etc. that's not with the system by default. All these can be loadable modules. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Bring back the Firefox plushy! http://digg.com/linux_unix/Is_the_Firefox_plush_gone_for_good https://bugzilla.mozilla.org/show_bug.cgi?id=322367 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Packaging and Hello World Tutorial
On Jan 1, 2008 7:03 PM, Kent Loobey [EMAIL PROTECTED] wrote: On Tuesday 01 January 2008 15:57:17 you wrote: I was trying a modification of the Hello World tutorial What is the URL to the Hello World tutorial of which you speak? Thanks. Started with: http://wiki.laptop.org/go/Sugar_Activity_Tutorial and then tried the differences present in: http://wiki.laptop.org/go/Creating_an_activity but the key seems to be the: find ./ | sed 's,^./,YourActivityName.activity/,g' MANIFEST The inclusion of YourActivityName.activity seems to be the key problem. -eric ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
John Richard Moser wrote: Please, build a kernel with the changes you consider useful, and make it available somewhere, along with your proposed config patch. Please make sure that the resulting kernel also still works on QEMU and VMware. The base hardware drivers built in supports qemu and vmware? Yes, but it doesn't take that much. It's probably just a pci IDE controller and the vesafb. Looks like I gotta read up on the wiki about how to rebuild the kernels (again). It seems I can alter Grub to do what I want afterwards though. (Do I need a developer's key or smth?) Yes, you do need a developer key. What is an smth? Rebuilding the kernel RPM is less than trivial. You may prefer just building the kernel and then copying it on the target with a stupid script like this one: ---8--- dest=18.85.46.119 stagedir=stage #vservers destdir=/versions/boot/current/boot #sane #destdir=/ set -x mkdir -p $stagedir/boot make INSTALL_MOD_PATH=$stagedir modules_install make bzImage cp -a arch/i386/boot/bzImage $stagedir/boot/vmlinuz cp -a System.map $stagedir/boot tar -C $stagedir -czf - . | ssh [EMAIL PROTECTED] tar -C $destdir -xvzf - ---8--- Extra bonus points if you can give hard numbers on memory saving and performance gains. Black art ;) Well, size vmlinux may be a lower bound approximation for the memory saving. Combined with some /proc/slabinfo magic you'd get closer. As you say, performance is hard to measure. Shell scripts tend to be good kernel benchmarks because they create lots of processes, file descriptors, and do a lot of I/O. I'd keep the debug symbols (which shouldn't cost any memory at runtime). Possibly not. The kernel runs inside one giant huge page doesn't it? 4MiB read-write-execute... Not on the Geode: we don't have MTRRs, so I guess the kernel is being mapped by 4KB pages. But anyway, aren't the symbols in a separate ELF section? So probably they end up in the vmlinuz binary too, but I've not checked. Because of this, I think all the modules required for booting off jffs2 and ext3 need to be linked in :-( I think you can omit booting off ext3 for the final product. Hmmm, people may like to boot off USB and SD, wouldn't they? We're talking about a very small saving anyway... There is load-time consideration to be made about loading everything as modules (camera, USB, mouse, all of networking, sound, etc) and leaving the essentials (flash, display, keyboard, jffs2). Even if you leave networking and all the 100%-always-loaded modules compiled in, however, there's no need for things like 30 types of file systems. We still have plenty of places where we could recover several *seconds* of boot time with just minor changes. So I don't think we should worry too much about module load time, which is probably very fast. In my experience, module load time is usually dominated by the work being done in the init function, which sometimes involves sleeping or performing slow I/O (i2c, serial, USB...). This time would also be spent in the monolithic kernel. I'd personally leave out ipv4 and ipv6 and just load them at boot time; I'd rather not have ipv6 loaded right now, and ipv6 infrastructures should run without ipv4 (some apps will probably complain about no 127.0.0.1...); but this is just nitpicking. I agree with you. Really I like a tiny core kernel and a bunch of modules but as I said, increases the time needed to boot. I once again agree with you, except that I don't think the load time increase will be problematic on the XO. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Bernardo Innocenti wrote: John Richard Moser wrote: Please, build a kernel with the changes you consider useful, and make it available somewhere, along with your proposed config patch. Please make sure that the resulting kernel also still works on QEMU and VMware. The base hardware drivers built in supports qemu and vmware? Yes, but it doesn't take that much. It's probably just a pci IDE controller and the vesafb. Looks like I gotta read up on the wiki about how to rebuild the kernels (again). It seems I can alter Grub to do what I want afterwards though. (Do I need a developer's key or smth?) Yes, you do need a developer key. What is an smth? something Rebuilding the kernel RPM is less than trivial. You may prefer just building the kernel and then copying it on the target with a stupid script like this one: tar -C $stagedir -czf - . | ssh [EMAIL PROTECTED] tar -C $destdir -xvzf - So glad right now that ssh doesn't allow blank password log-in. So very glad. Extra bonus points if you can give hard numbers on memory saving and performance gains. Black art ;) Well, size vmlinux may be a lower bound approximation for the memory saving. Combined with some /proc/slabinfo magic you'd get closer. As you say, performance is hard to measure. Shell scripts tend to be good kernel benchmarks because they create lots of processes, file descriptors, and do a lot of I/O. Point taken. I'd keep the debug symbols (which shouldn't cost any memory at runtime). Possibly not. The kernel runs inside one giant huge page doesn't it? 4MiB read-write-execute... Not on the Geode: we don't have MTRRs, so I guess the kernel is being mapped by 4KB pages. Remove hugetlbfs then. But anyway, aren't the symbols in a separate ELF section? So probably they end up in the vmlinuz binary too, but I've not checked. Because of this, I think all the modules required for booting off jffs2 and ext3 need to be linked in :-( I think you can omit booting off ext3 for the final product. Hmmm, people may like to boot off USB and SD, wouldn't they? We're talking about a very small saving anyway... Would you boot off the kernel on the flash and then load the system from the USB or SD, or use a kernel on the SD card? There is load-time consideration to be made about loading everything as modules (camera, USB, mouse, all of networking, sound, etc) and leaving the essentials (flash, display, keyboard, jffs2). Even if you leave networking and all the 100%-always-loaded modules compiled in, however, there's no need for things like 30 types of file systems. We still have plenty of places where we could recover several *seconds* of boot time with just minor changes. So I don't think we should worry too much about module load time, which is probably very fast. In my experience, module load time is usually dominated by the work being done in the init function, which sometimes involves sleeping or performing slow I/O (i2c, serial, USB...). This time would also be spent in the monolithic kernel. So this raises the question: By parallelizing boot and using an event-driven init system like Ubuntu's Upstart, could you actually get to running application code before loading the modules; and then set up all the hardware while more CPU-bound parts of the boot process run? Sort of bring up the system while all the devices are being initialized, just as long as graphics + keyboard + mouse are up for X to start when it gets there. I'd personally leave out ipv4 and ipv6 and just load them at boot time; I'd rather not have ipv6 loaded right now, and ipv6 infrastructures should run without ipv4 (some apps will probably complain about no 127.0.0.1...); but this is just nitpicking. I agree with you. Really I like a tiny core kernel and a bunch of modules but as I said, increases the time needed to boot. I once again agree with you, except that I don't think the load time increase will be problematic on the XO. -- Bring back the Firefox plushy! http://digg.com/linux_unix/Is_the_Firefox_plush_gone_for_good https://bugzilla.mozilla.org/show_bug.cgi?id=322367 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Bernardo Innocenti wrote: I'd keep the debug symbols (which shouldn't cost any memory at runtime). Possibly not. The kernel runs inside one giant huge page doesn't it? 4MiB read-write-execute... Not on the Geode: we don't have MTRRs, so I guess the kernel is being mapped by 4KB pages. 4MB page support is unrelated to MTRR support. (one is related to linear addresses, the other physical addresses; please see the Intel or AMD documentation on paging and caching) Geode LX supports 4MB pages, it is reported as such in CPUID, and should be used by the kernel. Also note that Geode LX has RCONFs instead of MTRRs, which have the same functionality, and they are all programmed properly by the firmware. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Tom Sylla wrote: Not on the Geode: we don't have MTRRs, so I guess the kernel is being mapped by 4KB pages. 4MB page support is unrelated to MTRR support. (one is related to linear addresses, the other physical addresses; please see the Intel or AMD documentation on paging and caching) Geode LX supports 4MB pages, it is reported as such in CPUID, and should be used by the kernel. Also note that Geode LX has RCONFs instead of MTRRs, which have the same functionality, and they are all programmed properly by the firmware. So I wonder why we couldn't use these to speed up access to the framebuffer in the amd_drv X driver. Jordan, what do you think? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
On Jan 1, 2008 9:50 PM, Bernardo Innocenti [EMAIL PROTECTED] wrote: So I wonder why we couldn't use these to speed up access to the framebuffer in the amd_drv X driver. I don't understand, this was always taken care of. http://openbios.org/viewvc/cpu/x86/pc/olpc/lxmsrs.fth?view=markuprevision=739root=OpenFirmware has: msr: .1810 fdfff000.fd000111. \ Video (write through), fbsize which is setting the framebuffer as write-combining. (the write through comment is incorrect) I don't have current hardware to check if this is the way things are at run-time (maybe something over-writes that register later), but it was all working fine at some point in the past. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Devel Digest, Vol 23, Issue 2
On Jan 1, 2008 5:10 PM, Arjun Sarwal [EMAIL PROTECTED] wrote: There is a telemedicine kit from India for about $200, and there are other possibilities. I have been encouraged by developments in blood chemistry measurements that do not require a needle stick. The first such product is likely to be a diabetic blood sugar meter, but the process applies to any small molecule with a distinctive spectrum. I also have friends in the medical software business. There is a Free Software implementation of the M language and the entire US Veterans Administration/DoD hospital software system for medical records, administration, pharmacy, and much more. Glad to hear of these. Any one of these things can be developed/run around/on the XO ? Hi Arjun, I've CCed Sameer Sawarkar of Neurosynaptic. They have successfully built a remote low cost diagnostic kit ( I think it's called ReMeDi) that can measure temperature, blood pressure, ECG and heartbeat (stethoscope) and perform other tasks. It won a prize at the World Economic Forum 2007. There was an article in businessweek here: http://images.businessweek.com/ss/07/11/1129_tech_pioneers/source/22.htm I hope maybe XO and ReMeDi can, in someway, be complementary. Regards, jaya ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
