Re: Representing Embedded Architectures at the Kernel Summit
On Jun 18, 2009, at 10:00 PM, Paul Mundt wrote: On Thu, Jun 18, 2009 at 09:59:20PM -0500, Kumar Gala wrote: On Jun 17, 2009, at 9:51 PM, Paul Mundt wrote: On Wed, Jun 17, 2009 at 09:31:48AM -0500, Kumar Gala wrote: One topic that was partially touched on was dealing with various memories on embedded systems. We have several sram based allocators in the kernel for various different arch's: - Blackfin sram allocator arch/blackfin/mm/sram-alloc.c - Lite5200(b) sram allocator arch/powerpc/sysdev/bestcomm/sram.c - AVR32 sram allocator arch/avr32/mach-at32ap/at32ap700x.c and arch/ avr32/mach-at32ap/include/mach/sram.h - Potential davinci sram allocator There maybe others. SH does this through NUMA on SRAM blocks that are anywhere from 128kB to 64MB. Some of our SMP configurations have upwards of a dozen of these blocks. Do you really have that much on chip memory? Is this really a serious question? If we didn't, I would not have mentioned it. It was. I'm not familiar with SH hardware so wasn't sure if there was some other application you had for the multiple regions. - k -- 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: Representing Embedded Architectures at the Kernel Summit
On Jun 17, 2009, at 9:51 PM, Paul Mundt wrote: On Wed, Jun 17, 2009 at 09:31:48AM -0500, Kumar Gala wrote: One topic that was partially touched on was dealing with various memories on embedded systems. We have several sram based allocators in the kernel for various different arch's: - Blackfin sram allocator arch/blackfin/mm/sram-alloc.c - Lite5200(b) sram allocator arch/powerpc/sysdev/bestcomm/sram.c - AVR32 sram allocator arch/avr32/mach-at32ap/at32ap700x.c and arch/ avr32/mach-at32ap/include/mach/sram.h - Potential davinci sram allocator There maybe others. SH does this through NUMA on SRAM blocks that are anywhere from 128kB to 64MB. Some of our SMP configurations have upwards of a dozen of these blocks. Do you really have that much on chip memory? - k -- 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: Representing Embedded Architectures at the Kernel Summit
On Thu, Jun 18, 2009 at 09:59:20PM -0500, Kumar Gala wrote: On Jun 17, 2009, at 9:51 PM, Paul Mundt wrote: On Wed, Jun 17, 2009 at 09:31:48AM -0500, Kumar Gala wrote: One topic that was partially touched on was dealing with various memories on embedded systems. We have several sram based allocators in the kernel for various different arch's: - Blackfin sram allocator arch/blackfin/mm/sram-alloc.c - Lite5200(b) sram allocator arch/powerpc/sysdev/bestcomm/sram.c - AVR32 sram allocator arch/avr32/mach-at32ap/at32ap700x.c and arch/ avr32/mach-at32ap/include/mach/sram.h - Potential davinci sram allocator There maybe others. SH does this through NUMA on SRAM blocks that are anywhere from 128kB to 64MB. Some of our SMP configurations have upwards of a dozen of these blocks. Do you really have that much on chip memory? Is this really a serious question? If we didn't, I would not have mentioned it. -- 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: Representing Embedded Architectures at the Kernel Summit
One topic that was partially touched on was dealing with various memories on embedded systems. We have several sram based allocators in the kernel for various different arch's: - Blackfin sram allocator arch/blackfin/mm/sram-alloc.c - Lite5200(b) sram allocator arch/powerpc/sysdev/bestcomm/sram.c - AVR32 sram allocator arch/avr32/mach-at32ap/at32ap700x.c and arch/ avr32/mach-at32ap/include/mach/sram.h - Potential davinci sram allocator There maybe others. - k -- 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: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 16, 2009 at 09:42:46AM +0300, Mike Rapoport wrote: James Bottomley wrote: We've got to the point where there are simply too many embedded architectures to invite all the arch maintainers to the kernel summit. So, this year, we thought we'd do embedded via topic driven invitations instead. So what we're looking for is a proposal to discuss the issues most affecting embedded architectures, or preview any features affecting the main kernel which embedded architectures might need ... or any other topics from embedded architectures which might need discussion or debate. Another issue that affects embedded architectures is drivers initialization order. There are a lot of cases when you need the drivers to be initialized in particular order, and current initcalls scheme does not allow fine grained control for it. Look at the early platform device abstraction, this allows specific fine-grained control over when certain drivers are initialized, well before the driver core is available. On SH this is how we deal with our system timers as clockevents/clocksources while just using regular platform devices, and having no other abstraction. You can read more in Documentation/driver-model/platform.txt. For an example, you can grep for earlytimer in arch/sh as well as in drivers/clocksource. -- 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: Representing Embedded Architectures at the Kernel Summit
James Bottomley wrote: Hi All, We've got to the point where there are simply too many embedded architectures to invite all the arch maintainers to the kernel summit. So, this year, we thought we'd do embedded via topic driven invitations instead. So what we're looking for is a proposal to discuss the issues most affecting embedded architectures, or preview any features affecting the main kernel which embedded architectures might need ... or any other topics from embedded architectures which might need discussion or debate. Another issue that affects embedded architectures is drivers initialization order. There are a lot of cases when you need the drivers to be initialized in particular order, and current initcalls scheme does not allow fine grained control for it. -- Sincerely yours, 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: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 16, 2009 at 02:42, Mike Rapoport wrote: James Bottomley wrote: We've got to the point where there are simply too many embedded architectures to invite all the arch maintainers to the kernel summit. So, this year, we thought we'd do embedded via topic driven invitations instead. So what we're looking for is a proposal to discuss the issues most affecting embedded architectures, or preview any features affecting the main kernel which embedded architectures might need ... or any other topics from embedded architectures which might need discussion or debate. Another issue that affects embedded architectures is drivers initialization order. There are a lot of cases when you need the drivers to be initialized in particular order, and current initcalls scheme does not allow fine grained control for it. example: device configuration information stored in i2c eeprom (i.e. dimensions of attached framebuffer), but i2c is not available when framebuffer layer is setup. framebuffer driver has to be built as a module and loaded by userspace, or i2c information is read by bootloader and passed down to the kernel. -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: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 16, 2009 at 2:06 AM, Mike Frysingervapier@gmail.com wrote: On Tue, Jun 16, 2009 at 02:42, Mike Rapoport wrote: James Bottomley wrote: Another issue that affects embedded architectures is drivers initialization order. There are a lot of cases when you need the drivers to be initialized in particular order, and current initcalls scheme does not allow fine grained control for it. example: device configuration information stored in i2c eeprom (i.e. dimensions of attached framebuffer), but i2c is not available when framebuffer layer is setup. framebuffer driver has to be built as a module and loaded by userspace, or i2c information is read by bootloader and passed down to the kernel. I experimented a bit with having some infrastructure for waiting for another device to get either registered as part of the phylib stuff I was doing. Here's the patchwork link to the discussion: http://patchwork.ozlabs.org/patch/24152/ I never actually pushed through and finished it because it turned out to be a non-issue for Ethernet devices in the end. However, I can see the value. With this approach, a driver can use a bus_register_notifier() variant without caring about the device registration order, and the drivers notifier callback will get called at the appropriate time. In your example case I could see the framebuffer driver deferring the final part of its initialization until the needed i2c device shows up. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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: Representing Embedded Architectures at the Kernel Summit
Grant Likely wrote: http://patchwork.ozlabs.org/patch/24152/ I never actually pushed through and finished it because it turned out to be a non-issue for Ethernet devices in the end. However, I can see the value. With this approach, a driver can use a bus_register_notifier() variant without caring about the device registration order, and the drivers notifier callback will get called at the appropriate time. In your example case I could see the framebuffer driver deferring the final part of its initialization until the needed i2c device shows up. It makes drivers more complicated and larger than necessary, though, having to add more functions and register more callbacks. Something which lets you specify a dependency in a one-line MODULE_INIT_PREREQS() macro would be much nicer. I can see the callbacks being useful, and necessary, for drivers which need to interleave their initialisation. E.g. need to initialise an external framebuffer chip before you can use it's I2C GPIOs, but then need to initialise an I2C driver before you can read the framebuffer parameters to finish setting up the framebuffer. -- Jamie -- 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: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokierja...@shareable.org wrote: Grant Likely wrote: http://patchwork.ozlabs.org/patch/24152/ I never actually pushed through and finished it because it turned out to be a non-issue for Ethernet devices in the end. However, I can see the value. With this approach, a driver can use a bus_register_notifier() variant without caring about the device registration order, and the drivers notifier callback will get called at the appropriate time. In your example case I could see the framebuffer driver deferring the final part of its initialization until the needed i2c device shows up. It makes drivers more complicated and larger than necessary, though, having to add more functions and register more callbacks. Something which lets you specify a dependency in a one-line MODULE_INIT_PREREQS() macro would be much nicer. That would work for some cases, but a lot of cases the problem is not module init order, but rather driver the probe order. ie. In the Ethernet case I was working on the mac cannot be opened before the phy_device is registered. Or another example is GPIOs. An GPIO driven SPI or MDIO bus cannot be probed before all the devices providing the GPIOs are probed (right now GPIOs are 'special' and probed early, but this is ugly and there is no reason it couldn't be handled within the Linux driver model. I could see some form of .probe_prereqs member of a device driver, but what form should it take? Callback? Data structure? The field of prereqs (or rather figuring out the prereqs) is so large that I don't feel confident trying to define something. A callback is probably the most flexible if it could be called after each probe or registration event on other devices. The idea being that if the prereq call fails, then it will be tried again later. Or, thinking further, perhaps instead of a .probe_prereq, just have .probe returns -ETRYAGAIN and make the driver core put the device on the end of the queue of devices to get probed. This could get ugly in the driver core though. Needs more thought g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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: Representing Embedded Architectures at the Kernel Summit
Grant Likely wrote: On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokierja...@shareable.org wrote: Something which lets you specify a dependency in a one-line MODULE_INIT_PREREQS() macro would be much nicer. That would work for some cases, but a lot of cases the problem is not module init order, but rather driver the probe order. ie. In the Ethernet case I was working on the mac cannot be opened before the phy_device is registered. Or another example is GPIOs. An GPIO driven SPI or MDIO bus cannot be probed before all the devices providing the GPIOs are probed (right now GPIOs are 'special' and probed early, but this is ugly and there is no reason it couldn't be handled within the Linux driver model. Both of those cases look like a simple module init order problem. I'm not seeing how it's a probe order problem. Even if you can probe PHYs independently first, how are they going to be bound to the ethernet MACs, other than by dodgy defaults? In any of your examples, is the modprobe symbol dependency order insufficient, when they are external modules? If the problem is simply that modprobe can calculate dependencies but linked-in modules don't, maybe the solution is to use the symbolic dependencies to calculate a linked-in driver initialisation order. If it's a probe order problem, where there aren't symbolic dependencies, then MODULE_PROVIDE(gpio) and MODULE_REQUIRE(gpio) or something like that might handle those cases, except for tricky ones like a GPIO-driven I2C bus which controls a GPIO chip. -- Jamie -- 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: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 16, 2009 at 2:07 PM, Jamie Lokierja...@shareable.org wrote: Grant Likely wrote: On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokierja...@shareable.org wrote: Something which lets you specify a dependency in a one-line MODULE_INIT_PREREQS() macro would be much nicer. That would work for some cases, but a lot of cases the problem is not module init order, but rather driver the probe order. ie. In the Ethernet case I was working on the mac cannot be opened before the phy_device is registered. Or another example is GPIOs. An GPIO driven SPI or MDIO bus cannot be probed before all the devices providing the GPIOs are probed (right now GPIOs are 'special' and probed early, but this is ugly and there is no reason it couldn't be handled within the Linux driver model. Both of those cases look like a simple module init order problem. I'm not seeing how it's a probe order problem. Even if you can probe PHYs independently first, how are they going to be bound to the ethernet MACs, other than by dodgy defaults? In any of your examples, is the modprobe symbol dependency order insufficient, when they are external modules? In both cases the driver is waiting for a specific instance, but has no idea which driver will provide that service. For the Ethernet example: Both the MAC driver and the MDIO bus driver are registered independently (say via either the platform bus). The MDIO bus driver creates a new mdio_bus instance and registers a phy_device for each child on the bus. The pdata for the MAC driver only contains the address of the phy, but it does not know which driver handles the MDIO bus and it does not know what driver will handle the phy. All the MAC cares about dereferencing the phy address to get a pointer to the phy_device structure which only works after the MDIO bus is probed and the correct phy_device is registered.. Module dependencies won't help here because the MAC cannot know what module to depend against. Plus, in some cases, the MAC will be used without a PHY, in which case it cannot depend on any phy modules. For the GPIO example, same thing. Something like the i2c-gpio driver doesn't know anything about which device provides the GPIO signals. It is only handled GPIO numbers for each signal and it cannot be probed before all the required GPIOs are registered with the system. Again module dependencies don't work because the driver doesn't know which GPIO driver it will get bound against at run time. If the problem is simply that modprobe can calculate dependencies but linked-in modules don't, maybe the solution is to use the symbolic dependencies to calculate a linked-in driver initialisation order. If it's a probe order problem, where there aren't symbolic dependencies, then MODULE_PROVIDE(gpio) and MODULE_REQUIRE(gpio) or something like that might handle those cases, except for tricky ones like a GPIO-driven I2C bus which controls a GPIO chip. Ugh it feels too coarse grained to me. It solves some of the problems, but still requires playing dirty tricks for the tricky cases which scuttles the whole lot. ie. your i2c GPIO chip example. Another driver wired to one of those 2nd level GPIOs and using MODULE_REQUIRE(gpio) would immediately be defeated and would need some other method to indicate the dependency. Plus there is the question when stuff is loaded as modules as to how does the kernel know when MODULE_PROVIDE(gpio) is complete? What if I load the gpio driver after the gpio-i2c driver? I'd much rather define the dependency at the resource level, not module level because that is what the driver is actually needing. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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: Representing Embedded Architectures at the Kernel Summit
On Wed, Jun 10, 2009 at 5:13 PM, Kumar Galaga...@kernel.crashing.org wrote: On Jun 2, 2009, at 5:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: I'd like to propose AMP and kernel relocate as more and SoC will came with multiple core with or without the same arch I think AMP or at least the idea of the kernel communicating with other OSes on the same SoC in multi-core systems is interesting. Indeed, and not just for SoCs. I'm currently looking at Ira's adaptation of virtio to use it for IPC between two separate CPUs running separate Linux instances and connected via PCI. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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: Representing Embedded Architectures at the Kernel Summit
On Jun 2, 2009, at 5:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: I'd like to propose AMP and kernel relocate as more and SoC will came with multiple core with or without the same arch I think AMP or at least the idea of the kernel communicating with other OSes on the same SoC in multi-core systems is interesting. - k -- 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: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 2, 2009 at 11:48 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
On Tue, 2009-06-02 at 11:29 -0600, Grant Likely wrote:
One topic that seems to garner debate is the issue of decoupling the
kernel image from the target platform. ie. On x86, PowerPC and Sparc
a kernel image will boot on any machine (assuming the needed drivers
are enabled), but this is rarely the case in embedded. Most embedded
kernels require explicit board support selected at compile time with
no way to produce a generic kernel which will boot on a whole family
of devices, let alone the whole architecture. Part of this is a
firmware issue, where existing firmware passes very little in the way
of hardware description to the kernel, but part is also not making
available any form of common language for describing the machine.
OK, so my minimal understanding in this area lead me to believe this was
because most embedded systems didn't have properly discoverable busses
and therefore you had to tailor the kernel configuration exactly to the
devices the system had.
Yes, mostly true. The kernel must be explicitly told the layout of
the non-discoverable busses and interconnects. One method is to use
per-machine statically compiled tables of platform devices, but
nothing forces embedded to do it that way...
I think that in the absence of any established standard like the PC
BIOS/EFI or a real Open Firmware interface, then the kernel should at
least offer a recommended interface so that multiplatform kernels are
possible without explicitly having the machine layout described to it
at compile time. I know that some of the embedded distros are
interested in such a thing since it gets them away from shipping
separate images for each supported board. ie. It's really hard to do
a generic live-cd without some form of multiplatform. FDT is a great
approach, but it probably isn't the only option. It would be worth
debating.
It sounds interesting ... however, it also sounds like an area which
might not impact the core kernel much ... or am I wrong about that? The
topics we're really looking for the Kernel Summit are ones that require
cross system input and which can't simply be sorted out by organising an
Embedded mini-summit.
Hmmm... in reading this thread and thinking about it more, I'm
beginning to think that it might really be a core kernel issue; or at
least a device driver policy one. Regardless of architecture, at boot
time Linux must use some method to discover the system layout, be it:
1) Reading BIOS/EFI/ACPI/OpenFirmware/FDT data
2) Probing the bus (PCI, USB, etc)
3) Compiled into the kernel (tables of platform devices, machine specific code)
Many types of devices could be end up being discovered using any of
the above methods. Ignoring for the time being the complexities and
history of the Linux UART drivers, I'm going to use 16550 serial ports
for an example. On ARM, a platform device for an 16550 serial port
may be instantiated by machine specific init code, on PowerPC it will
be discovered by a device tree parser, on a PC it could be a legacy
port, and on all three it could hang off a PCI device. The bus
connection and source of data are different in each case, but the same
core driver will handle all of them. The real differences are in
discovery and decoding the configuration.
SPI devices (struct spi_device) is possibly a better example.
spi_device drivers that need additional configuration go looking at
the platform_data pointer in the struct device. This is easy when the
device is hard coded into the kernel because the correct pdata struct
is initialized statically at build time. When the device is
discovered via one of the other mechanisms, the question remains of
where should the code live that does the translation and fills in the
correct pdata? The mmc_spi driver handles this by calling out to an
mmc_spi_get_pdata() function (drivers/spi/{mmc_spi,mmc_spi_of}.c. If
running on an OF platform, mmc_spi_get_pdata() has the knowledge to
decode the device tree data and munge it into the pdata form needed by
the driver. Both statically compiled and Device Tree described
mmc_spi configurations must be handled, and driver specific decode
methods must exist, but there I don't think there is any desire to
write multiple probe routines for each device driver. The same issue
stands for i2c, MMIO, and other non-discoverable busses.
For drivers which require pdata, writing decode functions is
unavoidable, but it is unclear how to hook in that code with as little
impact on a device driver as possible. To me the issue is, where
should that code live? and how should it get executed? (which is why
I think it is a device driver policy issue) I've used the example of
OF device tree bindings vs. static configuration, but it applies just
as readily to something like UEFI (ie. I see that ARM is a member of
the UEFI forum). Here are some of my unsorted thoughts on the
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 2, 2009 at 3:16 PM, Bill Gatliff b...@billgatliff.com wrote: Russell King wrote: The big problem we have is that the only commonality between different SoCs is that the CPU executes ARM instructions. Everything else is entirely up to the SoC designer - eg location of memory, spacing of memory banks, type of interrupt controller, etc is all highly SoC specific. Nothing outside of the ARM CPU itself is standardized. And that diversity is precisely because of the diversity in ARM-based embedded platforms. Such diversity means that kernel/driver development is a constant activity, which suggests that we shouldn't bother the effort to come up with a comprehensive solution because none will exist. Rather, we should maintain and improve the ability to rapidly prototype and adapt. Things like furthering the deployment of platform_device, clocksource/clockdevice, and so on. No, not comprehensive; just common. It makes sense to spend the effort on the patterns and devices which are common. It may not cover everything, but it doesn't have to to be valuable. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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: Representing Embedded Architectures at the Kernel Summit
On Wed, Jun 3, 2009 at 3:08 AM, Steve Langstaff steve.langst...@pebblebay.com wrote: From: linux-embedded-ow...@vger.kernel.org [mailto:linux-embedded- ow...@vger.kernel.org] On Behalf Of Russell King The big problem we have is that the only commonality between different SoCs is that the CPU executes ARM instructions. Everything else is entirely up to the SoC designer - eg location of memory, spacing of memory banks, type of interrupt controller, etc is all highly SoC specific. Nothing outside of the ARM CPU itself is standardized. To my naive ears it sounds like this problem is crying out for ARM and the SoC designers to add a standardized autoprobe interface to the core to allow discovery of machine type and/or location of memory, spacing of memory banks, type of interrupt controller, etc. The benefits of such mechanisms are well known, but what are the drawbacks? Local bus probing probably imposes a lot of assumptions on a bus designed to be as open as possible. How are chip selects wired up? What base addresses do devices respond to? How do you know what the device is? What IRQ lines are used? PCI solves this by exporting configuration space which defines all of this, but PCI is considerably more complex and not as fast as a CPU's local bus. Similarly busses like spi and i2c either have no probing protocol defined (spi), or cannot always be reliably probed (i2c). In short, the drawbacks are complexity on devices which cannot afford the complexity. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 02, 2009 at 05:48:37PM +, James Bottomley wrote: On Tue, 2009-06-02 at 11:29 -0600, Grant Likely wrote: firmware issue, where existing firmware passes very little in the way of hardware description to the kernel, but part is also not making available any form of common language for describing the machine. OK, so my minimal understanding in this area lead me to believe this was because most embedded systems didn't have properly discoverable busses and therefore you had to tailor the kernel configuration exactly to the devices the system had. Ish; essentially it's pushing the description of the non-enumerable bits of the hardware out of kernel code and into a separate bit of data that can be passed in to the kernel. It sounds interesting ... however, it also sounds like an area which might not impact the core kernel much ... or am I wrong about that? The topics we're really looking for the Kernel Summit are ones that require cross system input and which can't simply be sorted out by organising an Embedded mini-summit. One issue that does have wider impact is that the OpenFirmware bindings can affect any driver level code - it means that drivers may need to parse configuration out of the device tree as well as the mechanisms they normally use. This is already happening due to the current use but will become more visible if more platforms adopt the device tree. As someone primarily working on driver/subsystem side stuff this is my primary concern with expanded use of device tree - it's another set of platform data code that needs writing in addition to the other schemes currently in use. On the other hand, if all the embedded architectures got together and agreeded to move in this direction it'd be pretty much equivalent to some new BIOS standard being introduced for PCs so perhaps not worth worrying about at a general kernel level. Now if flattened device tree could help us out with BIOS, ACPI, EFI and the other myriad boot and identification standards that seem designed to hide system information rather than reveal it, then we might be all ears ... Well, you could potentially try to render other BIOS data tables into device tree format. I'm not sure that the translation would be less effort than parsing the existing data, though. -- 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: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 2, 2009 at 9:22 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: Hi All, We've got to the point where there are simply too many embedded architectures to invite all the arch maintainers to the kernel summit. So, this year, we thought we'd do embedded via topic driven invitations instead. So what we're looking for is a proposal to discuss the issues most affecting embedded architectures, or preview any features affecting the main kernel which embedded architectures might need ... or any other topics from embedded architectures which might need discussion or debate. If you'd like to do this, could you either reply to this email, or send proposals to: ksummit-2009-disc...@lists.linux-foundation.org Hi James, One topic that seems to garner debate is the issue of decoupling the kernel image from the target platform. ie. On x86, PowerPC and Sparc a kernel image will boot on any machine (assuming the needed drivers are enabled), but this is rarely the case in embedded. Most embedded kernels require explicit board support selected at compile time with no way to produce a generic kernel which will boot on a whole family of devices, let alone the whole architecture. Part of this is a firmware issue, where existing firmware passes very little in the way of hardware description to the kernel, but part is also not making available any form of common language for describing the machine. Embedded PowerPC and Microblaze has tackled this problem with the Flattened Device Tree data format which is derived from the OpenFirmware specifications, and there is some interest and debate (as discussed recently on the ARM mailing list) about making flattened device tree usable by ARM also (which I'm currently proof-of-concepting). Josh Boyer has already touched on discussing flattened device tree support at kernel summit in an email to the ksummit list last week (quoted below), and I'm wondering if a broader discussing would be warranted. I think that in the absence of any established standard like the PC BIOS/EFI or a real Open Firmware interface, then the kernel should at least offer a recommended interface so that multiplatform kernels are possible without explicitly having the machine layout described to it at compile time. I know that some of the embedded distros are interested in such a thing since it gets them away from shipping separate images for each supported board. ie. It's really hard to do a generic live-cd without some form of multiplatform. FDT is a great approach, but it probably isn't the only option. It would be worth debating. Cheers, g. On Thu, May 28, 2009 at 5:41 PM, Josh Boyer jwbo...@linux.vnet.ibm.com wrote: Not to hijack this entirely, but I'm wondering if we could tie in some of the cross-arch device tree discussions that have been taking place among the ppc, sparc, and arm developers. I know the existing OF code for ppc, sparc, and microblaze could probably use some consolidation and getting some of the arch maintainers together in a room might prove fruitful. Particularly if we are going to discuss how to make drivers work for device tree and standard platforms alike. josh -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 02, 2009 at 03:22:20PM +, James Bottomley wrote: Hi All, We've got to the point where there are simply too many embedded architectures to invite all the arch maintainers to the kernel summit. So, this year, we thought we'd do embedded via topic driven invitations instead. So what we're looking for is a proposal to discuss the issues most affecting embedded architectures, or preview any features affecting the main kernel which embedded architectures might need ... or any other topics from embedded architectures which might need discussion or debate. If you'd like to do this, could you either reply to this email, or send proposals to: ksummit-2009-disc...@lists.linux-foundation.org For those not following the ksummit list, below is the current list of suggested topics: PROPOSERTOPIC Jon Corbet How much do we owe sloppy application writers Jon Corbet The containers end game and how we get there Balbir SinghThe Hacking Hour Rafael Wysocki Regression tracking and kernel quality Jon Corbet Criteria for acceptance of kernel tracepoints Jesse BarnesProfiling and performance counters Eric Biederman Procedures for dealing with patent problems John Linville Patch review checklist Matthew Wilcox How to handle style-only patches Dan WilliamsRAID unification / stacked block devices Jiri Kosina User-space drivers - worth encouraging? Sam RavnborgShipping user-space components in the kernel Kay Sievers Establishment/maintenance of per-subsystem todo lists Steve Rostedt Improving changelogs Jon Corbet I/O bandwidth controllers (maybe minisummit report) Ted Ts'oPulseAudio and kernel interface issues Greg KH Generic architecture support and arch layer cleanup (Josh Boyer: add device tree discussion?) Dave Jones cpumasks, churn, and unending API changes Dirk HohndelIssues related to wireless technologies Jon Corbet Tracing: Merging utrace Ftrace mainline v. private debugging tools Non-ftrace visibility infrastructure Systemtap for kernel developers Marcel Holtmann Tracing and protocol dumping Some of these certainly impact embedded architectures and workloads. Examples would be Generic architecture support, arch layer cleanup, tracing, profiling and performance counters, userspace drivers, etc. Which leads me to suggest that it is at least worth having someone with an embedded focus at KS to simply keep an eye out for impacts of generic changes. Feature parity is something I often deal with in trying to keep ppc4xx up to speed with the rest of the archs in the kernel. josh -- 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: Representing Embedded Architectures at the Kernel Summit
On Tue, 2009-06-02 at 13:29 -0400, Josh Boyer wrote: Which leads me to suggest that it is at least worth having someone with an embedded focus at KS to simply keep an eye out for impacts of generic changes. Feature parity is something I often deal with in trying to keep ppc4xx up to speed with the rest of the archs in the kernel. We're fine with this, if that's how the embedded guys would like to do it ... how do you want to nominate the someone with an embedded focus? We chose the topic driven approach because that's the one it's easiest for the Kernel Summit Programme Committee to look at and make attendance decisions based upon. However, if all the embedded people want to choose their own representatives, that's fine by us too ... as long as you can devise a fair process. James -- 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: Representing Embedded Architectures at the Kernel Summit
On Tue, 2009-06-02 at 11:29 -0600, Grant Likely wrote: One topic that seems to garner debate is the issue of decoupling the kernel image from the target platform. ie. On x86, PowerPC and Sparc a kernel image will boot on any machine (assuming the needed drivers are enabled), but this is rarely the case in embedded. Most embedded kernels require explicit board support selected at compile time with no way to produce a generic kernel which will boot on a whole family of devices, let alone the whole architecture. Part of this is a firmware issue, where existing firmware passes very little in the way of hardware description to the kernel, but part is also not making available any form of common language for describing the machine. OK, so my minimal understanding in this area lead me to believe this was because most embedded systems didn't have properly discoverable busses and therefore you had to tailor the kernel configuration exactly to the devices the system had. Embedded PowerPC and Microblaze has tackled this problem with the Flattened Device Tree data format which is derived from the OpenFirmware specifications, and there is some interest and debate (as discussed recently on the ARM mailing list) about making flattened device tree usable by ARM also (which I'm currently proof-of-concepting). Josh Boyer has already touched on discussing flattened device tree support at kernel summit in an email to the ksummit list last week (quoted below), and I'm wondering if a broader discussing would be warranted. I think that in the absence of any established standard like the PC BIOS/EFI or a real Open Firmware interface, then the kernel should at least offer a recommended interface so that multiplatform kernels are possible without explicitly having the machine layout described to it at compile time. I know that some of the embedded distros are interested in such a thing since it gets them away from shipping separate images for each supported board. ie. It's really hard to do a generic live-cd without some form of multiplatform. FDT is a great approach, but it probably isn't the only option. It would be worth debating. It sounds interesting ... however, it also sounds like an area which might not impact the core kernel much ... or am I wrong about that? The topics we're really looking for the Kernel Summit are ones that require cross system input and which can't simply be sorted out by organising an Embedded mini-summit. Now if flattened device tree could help us out with BIOS, ACPI, EFI and the other myriad boot and identification standards that seem designed to hide system information rather than reveal it, then we might be all ears ... James -- 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: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 02, 2009 at 12:42:57PM -0500, James Bottomley wrote: On Tue, 2009-06-02 at 13:29 -0400, Josh Boyer wrote: Which leads me to suggest that it is at least worth having someone with an embedded focus at KS to simply keep an eye out for impacts of generic changes. Feature parity is something I often deal with in trying to keep ppc4xx up to speed with the rest of the archs in the kernel. We're fine with this, if that's how the embedded guys would like to do it ... how do you want to nominate the someone with an embedded focus? We chose the topic driven approach because that's the one it's easiest for the Kernel Summit Programme Committee to look at and make attendance decisions based upon. However, if all the embedded people want to choose their own representatives, that's fine by us too ... as long as you can devise a fair process. Now, James, I think you haven't been paying attention to the embedded Linux world...asking us to devise *any* process is much more chaotic than herding cats. Expecting something everyone agrees is fair would probably take until at least KS 2010. That being said, we have three people who are listed in MAINTAINERS under embedded Linux. We might start by seeing which of them might take up the mantle and vote on the linux-embedded mailing list. James -- 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: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 02, 2009 at 11:29:46AM -0600, Grant Likely wrote: On Tue, Jun 2, 2009 at 9:22 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: Hi All, We've got to the point where there are simply too many embedded architectures to invite all the arch maintainers to the kernel summit. So, this year, we thought we'd do embedded via topic driven invitations instead. So what we're looking for is a proposal to discuss the issues most affecting embedded architectures, or preview any features affecting the main kernel which embedded architectures might need ... or any other topics from embedded architectures which might need discussion or debate. If you'd like to do this, could you either reply to this email, or send proposals to: ksummit-2009-disc...@lists.linux-foundation.org Hi James, One topic that seems to garner debate is the issue of decoupling the kernel image from the target platform. ... Embedded PowerPC and Microblaze has tackled this problem with the Flattened Device Tree data format which is derived from the OpenFirmware specifications, and there is some interest and debate (as discussed recently on the ARM mailing list) about making flattened device tree usable by ARM also (which I'm currently proof-of-concepting). Josh Boyer has already touched on discussing flattened device tree support at kernel summit in an email to the ksummit list last week (quoted below), and I'm wondering if a broader discussing would be warranted. I absolutely agree with this. We have been using the flattened device tree on our MIPS platform to support multiple systems, and are close to posting a patch to the MIPS Linux mailing list. At least one other MIPS platform has indicated that they want to use the device tree. I think that in the absence of any established standard like the PC BIOS/EFI or a real Open Firmware interface, then the kernel should at least offer a recommended interface so that multiplatform kernels are possible without explicitly having the machine layout described to it at compile time. I know that some of the embedded distros are interested in such a thing since it gets them away from shipping separate images for each supported board. ie. It's really hard to do a generic live-cd without some form of multiplatform. FDT is a great approach, but it probably isn't the only option. It would be worth debating. Is there another possibility besides the device tree that people are using on 4 different architectures? We can't mandate support of the device tree for any particular architecture or platform, but we can make sure the device tree infrastructure is supported well enough that any architecture can pick it up easily. Doing so will also encourage support in bootloaders which may not currently do so. Should we decide to go this way, there probably a next step wherein we standardize the device tree entries for those devices that are shared across multiple architectures and platorms. This will likely be a never-ending and mostly thankless task, but will again make things easier in the long run. Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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: Representing Embedded Architectures at the Kernel Summit
On Tue, 2009-06-02 at 10:52 -0700, David VomLehn wrote: On Tue, Jun 02, 2009 at 12:42:57PM -0500, James Bottomley wrote: On Tue, 2009-06-02 at 13:29 -0400, Josh Boyer wrote: Which leads me to suggest that it is at least worth having someone with an embedded focus at KS to simply keep an eye out for impacts of generic changes. Feature parity is something I often deal with in trying to keep ppc4xx up to speed with the rest of the archs in the kernel. We're fine with this, if that's how the embedded guys would like to do it ... how do you want to nominate the someone with an embedded focus? We chose the topic driven approach because that's the one it's easiest for the Kernel Summit Programme Committee to look at and make attendance decisions based upon. However, if all the embedded people want to choose their own representatives, that's fine by us too ... as long as you can devise a fair process. Now, James, I think you haven't been paying attention to the embedded Linux world...asking us to devise *any* process is much more chaotic than herding cats. Expecting something everyone agrees is fair would probably take until at least KS 2010. That being said, we have three people who are listed in MAINTAINERS under embedded Linux. We might start by seeing which of them might take up the mantle and vote on the linux-embedded mailing list. Even for someone as inattentive as me, the general problems of getting embedded people to agree the sky is blue did impinge on the peripheral consciousness. Thus: If you can come up with such a process in a timely fashion then fine ... if not, we'll do the topic based one suggested by the PC. James -- 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: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 2, 2009 at 11:45 AM, David VomLehn dvoml...@cisco.com wrote: Should we decide to go this way, there probably a next step wherein we standardize the device tree entries for those devices that are shared across multiple architectures and platorms. This will likely be a never-ending and mostly thankless task, but will again make things easier in the long run. devicetree-disc...@ozlabs.org mailing list is your friend here. In PowerPC land we've mostly settled on the policy of not merging a driver before the device tree binding is documented, posted and reviewed. This weeds out a lot of common mistakes. I also think the stuff in Documentation/powerpc/dts-bindings needs to be moved out to a common location. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 02, 2009 at 01:25:32PM -0500, James Bottomley wrote: On Tue, 2009-06-02 at 10:52 -0700, David VomLehn wrote: On Tue, Jun 02, 2009 at 12:42:57PM -0500, James Bottomley wrote: On Tue, 2009-06-02 at 13:29 -0400, Josh Boyer wrote: Which leads me to suggest that it is at least worth having someone with an embedded focus at KS to simply keep an eye out for impacts of generic changes. Feature parity is something I often deal with in trying to keep ppc4xx up to speed with the rest of the archs in the kernel. We're fine with this, if that's how the embedded guys would like to do it ... how do you want to nominate the someone with an embedded focus? We chose the topic driven approach because that's the one it's easiest for the Kernel Summit Programme Committee to look at and make attendance decisions based upon. However, if all the embedded people want to choose their own representatives, that's fine by us too ... as long as you can devise a fair process. Now, James, I think you haven't been paying attention to the embedded Linux world...asking us to devise *any* process is much more chaotic than herding cats. Expecting something everyone agrees is fair would probably take until at least KS 2010. That being said, we have three people who are listed in MAINTAINERS under embedded Linux. We might start by seeing which of them might take up the mantle and vote on the linux-embedded mailing list. Even for someone as inattentive as me, the general problems of getting embedded people to agree the sky is blue did impinge on the peripheral consciousness. Thus: If you can come up with such a process in a timely fashion then fine ... if not, we'll do the topic based one suggested by the PC. Most of these are probably tired and old, but some possible topic suggestions: 1) Kernel binary bloat (again) 2) Encouraging upstream participation of Embedded distros Things like Moblin and Android are getting a lot of press these days, but embedded distros have been around for a while. Are we getting good participation from these vendors? Is there something we could be doing to encourage such participation? Has CELF helped with this at all? etc 3) Netbooks - the bridge between embedded and desktop? Is the flourish of low cost netbooks, some pre-installed with Linux, having any impact on how we review and develop general kernel code? One of the problems I struggle with is coming up with embedded topics general enough to be of interest to a broader set of both upstream kernel developers and the embedded community. Those that are general enough have either been discussed quite a bit already, or are already on the list of topics. Maybe I'm just not trying hard enough. josh -- 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: Representing Embedded Architectures at the Kernel Summit
Josh Boyer wrote: 2) Encouraging upstream participation of Embedded distros Things like Moblin and Android are getting a lot of press these days, but embedded distros have been around for a while. Are we getting good participation from these vendors? Is there something we could be doing to encourage such participation? Has CELF helped with this at all? etc CELF tries, but the progress is exceedingly slow. Recently we've been more focused on contracting specific feature work. (E.g. Squashfs mainlining). James Bottomley wrote: Even for someone as inattentive as me, the general problems of getting embedded people to agree the sky is blue did impinge on the peripheral consciousness. Thus: If you can come up with such a process in a timely fashion then fine ... if not, we'll do the topic based one suggested by the PC. With regard to a process to determine representatives, I'm not sure we need one. Based on participation and inclusion in MAINTAINERS, either Matt Mackall or David Woodhouse can represent most embedded issues just fine. And I can say that officially on behalf of CELF and it's members, which would account for a large fraction of the overall embedded community. With regard to topics, do topics drive attendee invitations, or vice-versa? Here's my own issue list: tracing - already well (over?) represented bloat - tracing will help identify performance bloat. As for size bloat, a smaller kernel is always desirable, but we are seeing signs that Moore's law is catching up and making this less an issue (for the kernel - apps still have big problems here.) power management - Use cases for products that spend most of their time off (even while appearing to be running) are of interest. I don't know what the status 'wakelock-like' solutions is. fast boot - kernel is almost done? (!!!) The new target for kernel boot time is 300 milliseconds. Once there, almost all problems are then user space issues. It is interesting how much of a differentiator fast boot became for Linux in netbooks and dual-boot configurations, in just the last 2 years - which just shows that sometimes it pays off to optimize something. ;-) participation - talking about this is like beating a dead horse (for me at least). I've been working on this for 5 years now, making baby steps forward. The issues are, by now, well understood (I hope). I'm not sure what a KS discussion is going to do to drive issues here. = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- 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: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 02, 2009 at 11:29:46AM -0600, Grant Likely wrote: Embedded PowerPC and Microblaze has tackled this problem with the Flattened Device Tree data format which is derived from the OpenFirmware specifications, and there is some interest and debate (as discussed recently on the ARM mailing list) about making flattened device tree usable by ARM also (which I'm currently proof-of-concepting). Note that I have to point out that ARM will probably never be in a situation where you can have a one kernel image boots on everything. That _is_ practical today (and does happen with all PXA now) with what we have within a very big restriction - which is that the kernel must be built to support PXA and not Atmel SoCs. I really don't think combining SoC support is going to be realistic, device tree or not. When we had just four machine types (RiscPC, EBSA110, EBSA285, Netwinder) I did look into this and came to the conclusion that it would be far too inefficient for there to be any win. The big problem we have is that the only commonality between different SoCs is that the CPU executes ARM instructions. Everything else is entirely up to the SoC designer - eg location of memory, spacing of memory banks, type of interrupt controller, etc is all highly SoC specific. Nothing outside of the ARM CPU itself is standardized. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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: Representing Embedded Architectures at the Kernel Summit
Russell King wrote: The big problem we have is that the only commonality between different SoCs is that the CPU executes ARM instructions. Everything else is entirely up to the SoC designer - eg location of memory, spacing of memory banks, type of interrupt controller, etc is all highly SoC specific. Nothing outside of the ARM CPU itself is standardized. And that diversity is precisely because of the diversity in ARM-based embedded platforms. Such diversity means that kernel/driver development is a constant activity, which suggests that we shouldn't bother the effort to come up with a comprehensive solution because none will exist. Rather, we should maintain and improve the ability to rapidly prototype and adapt. Things like furthering the deployment of platform_device, clocksource/clockdevice, and so on. ARM diversity is already a LOT easier to deal with than it was under 2.4, so we're making progress. 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: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 02, 2009 at 10:10:58PM +0100, Russell King wrote: I really don't think combining SoC support is going to be realistic, device tree or not. When we had just four machine types (RiscPC, EBSA110, EBSA285, Netwinder) I did look into this and came to the conclusion that it would be far too inefficient for there to be any win. The big problem we have is that the only commonality between different SoCs is that the CPU executes ARM instructions. Everything else is entirely up to the SoC designer - eg location of memory, spacing of memory banks, type of interrupt controller, etc is all highly SoC specific. Nothing outside of the ARM CPU itself is standardized. And even with the cpu core, we usually build kernels with optimized toolchains for their cpu family. But nevertheless - describing hardware inside a mach* makes sense. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: Representing Embedded Architectures at the Kernel Summit
On 13:29 Tue 02 Jun , Josh Boyer wrote: On Tue, Jun 02, 2009 at 03:22:20PM +, James Bottomley wrote: Hi All, We've got to the point where there are simply too many embedded architectures to invite all the arch maintainers to the kernel summit. So, this year, we thought we'd do embedded via topic driven invitations instead. So what we're looking for is a proposal to discuss the issues most affecting embedded architectures, or preview any features affecting the main kernel which embedded architectures might need ... or any other topics from embedded architectures which might need discussion or debate. If you'd like to do this, could you either reply to this email, or send proposals to: ksummit-2009-disc...@lists.linux-foundation.org For those not following the ksummit list, below is the current list of suggested topics: PROPOSERTOPIC Jon Corbet How much do we owe sloppy application writers Jon Corbet The containers end game and how we get there Balbir SinghThe Hacking Hour Rafael Wysocki Regression tracking and kernel quality Jon Corbet Criteria for acceptance of kernel tracepoints Jesse BarnesProfiling and performance counters Eric Biederman Procedures for dealing with patent problems John Linville Patch review checklist Matthew Wilcox How to handle style-only patches Dan WilliamsRAID unification / stacked block devices Jiri Kosina User-space drivers - worth encouraging? Sam RavnborgShipping user-space components in the kernel Kay Sievers Establishment/maintenance of per-subsystem todo lists Steve Rostedt Improving changelogs Jon Corbet I/O bandwidth controllers (maybe minisummit report) Ted Ts'oPulseAudio and kernel interface issues Greg KH Generic architecture support and arch layer cleanup (Josh Boyer: add device tree discussion?) Dave Jones cpumasks, churn, and unending API changes Dirk HohndelIssues related to wireless technologies Jon Corbet Tracing: Merging utrace Ftrace mainline v. private debugging tools Non-ftrace visibility infrastructure Systemtap for kernel developers Marcel Holtmann Tracing and protocol dumping I'd like to propose AMP and kernel relocate as more and SoC will came with multiple core with or without the same arch Best Regards, J. -- 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
