Re: [PATCH 08/16 v2] pramfs: headers
2010/11/8 Ryan Mallon r...@bluewatersys.com:
On 11/08/2010 08:49 PM, Marco Stornelli wrote:
2010/11/7 Ryan Mallon r...@bluewatersys.com:
On 11/06/2010 09:58 PM, Marco Stornelli wrote:
From: Marco Stornelli marco.storne...@gmail.com
Definitions for the PRAMFS filesystem.
Signed-off-by: Marco Stornelli marco.storne...@gmail.com
---
diff -Nurp linux-2.6.36-orig/fs/pramfs/pram.h linux-2.6.36/fs/pramfs/pram.h
--- linux-2.6.36-orig/fs/pramfs/pram.h 1970-01-01
01:00:00.0 +0100
+++ linux-2.6.36/fs/pramfs/pram.h 2010-10-30 12:02:45.0 +0200
@@ -0,0 +1,317 @@
+/*
+ * Structure of the super block in PRAMFS
+ */
+struct pram_super_block {
+ __be16 s_sum; /* checksum of this sb, including padding */
+ __be64 s_size; /* total size of fs in bytes */
+ __be32 s_blocksize; /* blocksize in bytes */
+ __be32 s_inodes_count; /* total inodes count (used or free) */
+ __be32 s_free_inodes_count;/* free inodes count */
+ __be32 s_free_inode_hint; /* start hint for locating free inodes */
+ __be32 s_blocks_count; /* total data blocks count (used or free) */
+ __be32 s_free_blocks_count;/* free data blocks count */
+ __be32 s_free_blocknr_hint;/* free data blocks count */
+ __be64 s_bitmap_start; /* data block in-use bitmap location */
+ __be32 s_bitmap_blocks;/* size of bitmap in number of blocks */
+ __be32 s_mtime; /* Mount time */
+ __be32 s_wtime; /* Write time */
+ __be16 s_magic; /* Magic signature */
+ char s_volume_name[16]; /* volume name */
+};
Is there a particular reason to use big endian types for the data
structures? On a little endian machine you will end up converting values
everywhere. I assume that you don't expect the machine to change
endianess between reboots :-). If this is for generating/reading
filesystems from userspace, wouldn't it be better to have the userspace
tools specify the target endianess and do the conversions there?
~Ryan
Yes, there is a reason. In the first review a comment was: the fs must
have a fix endianess layout. This fs is designed for the embedded
world mainly. Since most of cpus used in this case are big-endian, it
means that for typical use case, there is no cost for endianess
conversion.
ARM, which is a large portion of the embedded space, is typically little
endian.
Not always. Indeed, I didn't say *all* cpu used are big-endian.
Why does a filesystem need to have a specific endianess layout?
Especially for a highly specialised filesystem like this.
I didn't agree with it, but in the first review there was more than
one developer that said this thing. The main reason was to read the
format (for example with JTAG) or to create an image with a fix
format. I remember that someone said that there was a similar problem
with jffs2 and the experience tell to us that a fix endianess is
important. At that point I decided to use big-endian. You can see all
the discussion in lkml. The review has been done at June 2009.
Regards,
Marco
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Embedded Linux Flag Version
On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote: It was noted at the summit that several CE companies and embedded projects will be using (or are already using) 2.6.35 for upcoming products or releases. This includes Sony, Google, Meego, and Linaro. On behalf of the CE Linux Forum and a number of consumer electronics companies, projects and community developers, we therefore declare 2.6.35 as a flag version of the kernel for embedded use. Several companies will be investing in development, integration and testing of this version. Entities wanting to do business with those companies would therefore be well-advised to make sure their hardware, drivers and enhancements work well with this version of the kernel. wouldnt it make more sense to piggy back the extensive work going into the stable tree ? many of the points you raise after all are the entire founding point of it. plus, all the main distros form around that, are spending time working on that, is marked as supported for 2 or 3 years, and there is already infrastructure/framework/process in place (sta...@kernel.org). so instead of picking arbitrary versions (like 2.6.35) and needlessly replicating the huge work load, simply declare these stable trees as the flag versions. that means today it'd be 2.6.32.y. -mike -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Embedded Linux Flag Version
On 11/09/2010 03:19 AM, Mike Frysinger wrote: On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote: It was noted at the summit that several CE companies and embedded projects will be using (or are already using) 2.6.35 for upcoming products or releases. This includes Sony, Google, Meego, and Linaro. On behalf of the CE Linux Forum and a number of consumer electronics companies, projects and community developers, we therefore declare 2.6.35 as a flag version of the kernel for embedded use. Several companies will be investing in development, integration and testing of this version. Entities wanting to do business with those companies would therefore be well-advised to make sure their hardware, drivers and enhancements work well with this version of the kernel. wouldnt it make more sense to piggy back the extensive work going into the stable tree ? many of the points you raise after all are the entire founding point of it. plus, all the main distros form around that, are spending time working on that, is marked as supported for 2 or 3 years, and there is already infrastructure/framework/process in place (sta...@kernel.org). so instead of picking arbitrary versions (like 2.6.35) and needlessly replicating the huge work load, simply declare these stable trees as the flag versions. that means today it'd be 2.6.32.y. The fact that this tree is already a year old, and not likely to be brought forward for at least another 2 years is the reason we didn't choose it this time. Most of the high-profile, active embedded projects are already on 2.6.35. For companies looking to adopt a new base kernel in the next 12 months, I don't want to have them start with a year-old kernel. We did consider the utility of synchronizing with the enterprise stable tree, but the timing just didn't work too well this time around. = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Network Entertainment = -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Embedded Linux Flag Version
On Tue, 09 Nov 2010, Tim Bird wrote: On 11/09/2010 03:19 AM, Mike Frysinger wrote: On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote: It was noted at the summit that several CE companies and embedded projects will be using (or are already using) 2.6.35 for upcoming products or releases. This includes Sony, Google, Meego, and Linaro. On behalf of the CE Linux Forum and a number of consumer electronics companies, projects and community developers, we therefore declare 2.6.35 as a flag version of the kernel for embedded use. Several companies will be investing in development, integration and testing of this version. Entities wanting to do business with those companies would therefore be well-advised to make sure their hardware, drivers and enhancements work well with this version of the kernel. wouldnt it make more sense to piggy back the extensive work going into the stable tree ? many of the points you raise after all are the entire founding point of it. plus, all the main distros form around that, are spending time working on that, is marked as supported for 2 or 3 years, and there is already infrastructure/framework/process in place (sta...@kernel.org). so instead of picking arbitrary versions (like 2.6.35) and needlessly replicating the huge work load, simply declare these stable trees as the flag versions. that means today it'd be 2.6.32.y. The fact that this tree is already a year old, and not likely to be brought forward for at least another 2 years is the reason we didn't choose it this time. Most of the high-profile, active embedded projects are already on 2.6.35. For companies looking to adopt a new base kernel in the next 12 months, I don't want to have them start with a year-old kernel. We did consider the utility of synchronizing with the enterprise stable tree, but the timing just didn't work too well this time around. I guess one of the key issues is that it would need to be defined beforehand what version will be used as the next flag version so vendors could make sure that there drivers are available. Further if such a selection were to be made then there would need to be consesus on maintaining the respective version for a sufficiently long time to allow for the next flag version to evolve. Finally for those working on products even if you would now define the current version as the flag version it would not help much as they would hardly be able to shift to a different kernel short term - so again the key is defining what version would be atleast planed for the next flag version - something like now defining it to be 2.6.38 - and then testing appropriately in the runup to 2.6.38 to deliver, most notably for the embedded architectures. thx! hofrat -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Embedded Linux Flag Version
On 11/09/2010 09:25 AM, Nicholas Mc Guire wrote: I guess one of the key issues is that it would need to be defined beforehand what version will be used as the next flag version so vendors could make sure that there drivers are available. Yeah. People keep asking about that. Unfortunately, this was not discussed or settled on - so I can't really comment on that as an industry representative. However, I will say that we'd like to work to synchronize our next flag version with the next enterprise stable release. (But again, it will depend on timing). Personally (not speaking on behalf of anyone else here), I think there would be a certain poetry to selecting 2.6.42 (which may just also be the same as or one before kernel version 3.1) ;-) -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Network Entertainment = -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Embedded Linux Flag Version
On Tue, 9 Nov 2010, Nicholas Mc Guire wrote: On Tue, 09 Nov 2010, Tim Bird wrote: On 11/09/2010 03:19 AM, Mike Frysinger wrote: On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote: It was noted at the summit that several CE companies and embedded projects will be using (or are already using) 2.6.35 for upcoming products or releases. This includes Sony, Google, Meego, and Linaro. On behalf of the CE Linux Forum and a number of consumer electronics companies, projects and community developers, we therefore declare 2.6.35 as a flag version of the kernel for embedded use. Several companies will be investing in development, integration and testing of this version. Entities wanting to do business with those companies would therefore be well-advised to make sure their hardware, drivers and enhancements work well with this version of the kernel. wouldnt it make more sense to piggy back the extensive work going into the stable tree ? many of the points you raise after all are the entire founding point of it. plus, all the main distros form around that, are spending time working on that, is marked as supported for 2 or 3 years, and there is already infrastructure/framework/process in place (sta...@kernel.org). so instead of picking arbitrary versions (like 2.6.35) and needlessly replicating the huge work load, simply declare these stable trees as the flag versions. that means today it'd be 2.6.32.y. The fact that this tree is already a year old, and not likely to be brought forward for at least another 2 years is the reason we didn't choose it this time. Most of the high-profile, active embedded projects are already on 2.6.35. For companies looking to adopt a new base kernel in the next 12 months, I don't want to have them start with a year-old kernel. We did consider the utility of synchronizing with the enterprise stable tree, but the timing just didn't work too well this time around. I guess one of the key issues is that it would need to be defined beforehand what version will be used as the next flag version so vendors could make sure that there drivers are available. Further if such a selection were to be made then there would need to be consesus on maintaining the respective version for a sufficiently long time to allow for the next flag version to evolve. Finally for those working on products even if you would now define the current version as the flag version it would not help much as they would hardly be able to shift to a different kernel short term - so again the key is defining what version would be atleast planed for the next flag version - something like now defining it to be 2.6.38 - and then testing appropriately in the runup to 2.6.38 to deliver, most notably for the embedded architectures. FWIW, the imminent Linaro release is using 2.6.35. The next release scheduled for May 2011 will most probably use 2.6.38. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/16 v2] pramfs: headers
On 11/09/2010 09:19 PM, Marco Stornelli wrote:
2010/11/8 Ryan Mallon r...@bluewatersys.com:
On 11/08/2010 08:49 PM, Marco Stornelli wrote:
2010/11/7 Ryan Mallon r...@bluewatersys.com:
On 11/06/2010 09:58 PM, Marco Stornelli wrote:
From: Marco Stornelli marco.storne...@gmail.com
Definitions for the PRAMFS filesystem.
Signed-off-by: Marco Stornelli marco.storne...@gmail.com
---
diff -Nurp linux-2.6.36-orig/fs/pramfs/pram.h
linux-2.6.36/fs/pramfs/pram.h
--- linux-2.6.36-orig/fs/pramfs/pram.h1970-01-01
01:00:00.0 +0100
+++ linux-2.6.36/fs/pramfs/pram.h 2010-10-30 12:02:45.0 +0200
@@ -0,0 +1,317 @@
+/*
+ * Structure of the super block in PRAMFS
+ */
+struct pram_super_block {
+ __be16 s_sum; /* checksum of this sb, including padding */
+ __be64 s_size; /* total size of fs in bytes */
+ __be32 s_blocksize;/* blocksize in bytes */
+ __be32 s_inodes_count; /* total inodes count (used or free) */
+ __be32 s_free_inodes_count;/* free inodes count */
+ __be32 s_free_inode_hint; /* start hint for locating free inodes
*/
+ __be32 s_blocks_count; /* total data blocks count (used or free) */
+ __be32 s_free_blocks_count;/* free data blocks count */
+ __be32 s_free_blocknr_hint;/* free data blocks count */
+ __be64 s_bitmap_start; /* data block in-use bitmap location */
+ __be32 s_bitmap_blocks;/* size of bitmap in number of blocks */
+ __be32 s_mtime;/* Mount time */
+ __be32 s_wtime;/* Write time */
+ __be16 s_magic;/* Magic signature */
+ chars_volume_name[16]; /* volume name */
+};
Is there a particular reason to use big endian types for the data
structures? On a little endian machine you will end up converting values
everywhere. I assume that you don't expect the machine to change
endianess between reboots :-). If this is for generating/reading
filesystems from userspace, wouldn't it be better to have the userspace
tools specify the target endianess and do the conversions there?
~Ryan
Yes, there is a reason. In the first review a comment was: the fs must
have a fix endianess layout. This fs is designed for the embedded
world mainly. Since most of cpus used in this case are big-endian, it
means that for typical use case, there is no cost for endianess
conversion.
ARM, which is a large portion of the embedded space, is typically little
endian.
Not always. Indeed, I didn't say *all* cpu used are big-endian.
My point is that little endian embedded machines make up a large portion
of the devices that this filesystem will be useful on. On those devices
it will also have an (unnecessary) conversion overhead.
Why does a filesystem need to have a specific endianess layout?
Especially for a highly specialised filesystem like this.
I didn't agree with it, but in the first review there was more than
one developer that said this thing. The main reason was to read the
format (for example with JTAG) or to create an image with a fix
format. I remember that someone said that there was a similar problem
with jffs2 and the experience tell to us that a fix endianess is
important. At that point I decided to use big-endian. You can see all
the discussion in lkml. The review has been done at June 2009.
You can still do all of those things without having a fixed endianess.
You just have to have one extra step of telling the external tools what
the endianess is. IMHO, it is better to have the overhead of the endian
conversion in the tools since it is less costly there than an the
embedded system.
I'm just trying to understand why the fixed endianess rule cannot be
bent for such a specialised filesystem.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
r...@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/16 v2] pramfs: headers
On Tue, Nov 9, 2010 at 21:35, Ryan Mallon r...@bluewatersys.com wrote:
On 11/09/2010 09:19 PM, Marco Stornelli wrote:
2010/11/8 Ryan Mallon r...@bluewatersys.com:
On 11/08/2010 08:49 PM, Marco Stornelli wrote:
2010/11/7 Ryan Mallon r...@bluewatersys.com:
On 11/06/2010 09:58 PM, Marco Stornelli wrote:
From: Marco Stornelli marco.storne...@gmail.com
Definitions for the PRAMFS filesystem.
Signed-off-by: Marco Stornelli marco.storne...@gmail.com
---
diff -Nurp linux-2.6.36-orig/fs/pramfs/pram.h
linux-2.6.36/fs/pramfs/pram.h
--- linux-2.6.36-orig/fs/pramfs/pram.h 1970-01-01
01:00:00.0 +0100
+++ linux-2.6.36/fs/pramfs/pram.h 2010-10-30 12:02:45.0 +0200
@@ -0,0 +1,317 @@
+/*
+ * Structure of the super block in PRAMFS
+ */
+struct pram_super_block {
+ __be16 s_sum; /* checksum of this sb, including padding
*/
+ __be64 s_size; /* total size of fs in bytes */
+ __be32 s_blocksize; /* blocksize in bytes */
+ __be32 s_inodes_count; /* total inodes count (used or free) */
+ __be32 s_free_inodes_count;/* free inodes count */
+ __be32 s_free_inode_hint; /* start hint for locating free inodes
*/
+ __be32 s_blocks_count; /* total data blocks count (used or free)
*/
+ __be32 s_free_blocks_count;/* free data blocks count */
+ __be32 s_free_blocknr_hint;/* free data blocks count */
+ __be64 s_bitmap_start; /* data block in-use bitmap location */
+ __be32 s_bitmap_blocks;/* size of bitmap in number of blocks */
+ __be32 s_mtime; /* Mount time */
+ __be32 s_wtime; /* Write time */
+ __be16 s_magic; /* Magic signature */
+ char s_volume_name[16]; /* volume name */
+};
Is there a particular reason to use big endian types for the data
structures? On a little endian machine you will end up converting values
everywhere. I assume that you don't expect the machine to change
endianess between reboots :-). If this is for generating/reading
filesystems from userspace, wouldn't it be better to have the userspace
tools specify the target endianess and do the conversions there?
~Ryan
Yes, there is a reason. In the first review a comment was: the fs must
have a fix endianess layout. This fs is designed for the embedded
world mainly. Since most of cpus used in this case are big-endian, it
means that for typical use case, there is no cost for endianess
conversion.
ARM, which is a large portion of the embedded space, is typically little
endian.
Not always. Indeed, I didn't say *all* cpu used are big-endian.
My point is that little endian embedded machines make up a large portion
of the devices that this filesystem will be useful on. On those devices
it will also have an (unnecessary) conversion overhead.
Why does a filesystem need to have a specific endianess layout?
Especially for a highly specialised filesystem like this.
I didn't agree with it, but in the first review there was more than
one developer that said this thing. The main reason was to read the
format (for example with JTAG) or to create an image with a fix
format. I remember that someone said that there was a similar problem
with jffs2 and the experience tell to us that a fix endianess is
important. At that point I decided to use big-endian. You can see all
the discussion in lkml. The review has been done at June 2009.
You can still do all of those things without having a fixed endianess.
You just have to have one extra step of telling the external tools what
the endianess is. IMHO, it is better to have the overhead of the endian
conversion in the tools since it is less costly there than an the
embedded system.
I'm just trying to understand why the fixed endianess rule cannot be
bent for such a specialised filesystem.
When it was decided that filesystems should be fixed-endian and support for
big-endian ext2 was dropped, the overhead of doing the fixed conversions was
deetermined negligible due to compiler optimization.
That was ages ago, and current embedded systems run circles around the
machines of those days.
Note that this is about metadata only. Actual file contents are always just
byte streams.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Avoiding platform-specific callbacks in drivers?
Guys: Let's say that on a given platform, I need to twiddle with a GPIO pin when a chip enters and exits suspend. One way to do that is to hack the driver itself; a slightly less-inelegant way is to add a function pointer in the platform data, and have the driver call back in its suspend() and resume() methods. I'm not real keen on either strategy, because they both involve touching driver code that should be platform-agnostic. They seem... hacky. :) I would love to come up with a way that prevents touching the driver at all, since the activity is terribly platform-specific. Is there such a way? One possibility is to set up some sort of parent-child relationship between the device and a pseudo-device that deals with the GPIO pin. But I'm not sure that will actually work, and it seems a bit overly-complicated. Ideas, anyone? I'll be happy to try them out if they seem feasible, and post code and feedback. b.g. -- Bill Gatliff b...@billgatliff.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Avoiding platform-specific callbacks in drivers?
On Tue, 9 Nov 2010, Bill Gatliff wrote: Let's say that on a given platform, I need to twiddle with a GPIO pin when a chip enters and exits suspend. What driver? What platform? This may depend on those. One way to do that is to hack the driver itself; a slightly less-inelegant way is to add a function pointer in the platform data, and have the driver call back in its suspend() and resume() methods. I'm not real keen on either strategy, because they both involve touching driver code that should be platform-agnostic. They seem... hacky. :) Sure. but if it makes sense for your hardware to do this GPIO twiddling, maybe someone else is doing that too. In which case a driver solution might be justifiable. I would love to come up with a way that prevents touching the driver at all, since the activity is terribly platform-specific. Is there such a way? One possibility is to set up some sort of parent-child relationship between the device and a pseudo-device that deals with the GPIO pin. But I'm not sure that will actually work, and it seems a bit overly-complicated. That would still be your best bet. The pseudo-device could register the real device and set itself as the parent. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Avoiding platform-specific callbacks in drivers?
Guys: Let's say that on a given platform, I need to twiddle with a GPIO pin when a chip enters and exits suspend. One way to do that is to hack the driver itself; a slightly less-inelegant way is to add a function pointer in the platform data, and have the driver call back in its suspend() and resume() methods. I'm not real keen on either strategy, because they both involve touching driver code that should be platform-agnostic. They seem... hacky. :) I would love to come up with a way that prevents touching the driver at all, since the activity is terribly platform-specific. Is there such a way? One possibility is to set up some sort of parent-child relationship between the device and a pseudo-device that deals with the GPIO pin. But I'm not sure that will actually work, and it seems a bit overly-complicated. Ideas, anyone? I'll be happy to try them out if they seem feasible, and post code and feedback. b.g. Isn't the general approach to avoid platform-dependencies to abstract the behavior? As is used throughout the kernel, an operations struct that provides the abstractions and each driver fills in its implementation as required. The polymorphism approach. Maybe the operations are begin_suspend() and end_suspend() and in this case the functions twiddle a GPIO pin? -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Avoiding platform-specific callbacks in drivers?
Kevin: On Tue, Nov 9, 2010 at 6:02 PM, Kevin Dankwardt k...@kcomputing.com wrote: Isn't the general approach to avoid platform-dependencies to abstract the behavior? As is used throughout the kernel, an operations struct that provides the abstractions and each driver fills in its implementation as required. The polymorphism approach. Maybe the operations are begin_suspend() and end_suspend() and in this case the functions twiddle a GPIO pin? The begin_suspend()/end_suspend() approach just moves the problem, really. Unless you put those function pointers into the platform data, you can't change them without touching the driver code. And if you do put those function pointers into the platform data, that seems an awful lot like open-coding. Gets the job done, but seems a fairly blunt instrument. In my case, the device model itself already provides the answer. The GPIO twiddling can be dealt with by implementing a pseudo-device that registers the actual device underneath it. Then the pseudo device neatly gets the suspend/resume events at the right times relative to the device. AND you get the benefits of sysfs and debugfs for free. I knew the answer was there; it just took an expert like Nicolas Pitre to point out the obvious to me. I can be so dense sometimes! :) b.g. -- Bill Gatliff b...@billgatliff.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
