Remote IP setup of devices in a network
I am faced with a challenge that we ship devices which are all preconfigured to a fixed IP address, and we want to provide an easy solution to do remote IP configuration of all devices connected to the same network. In other words - all devices are reachable by a broadcast package. The network may or may not include a DHCP server - which we in any case do not have control over. In the typical situation we will assign static IP addresses to the devices - but sometimes we may also configure them to DHCP. So we are looking for a (de facto?) way to do this. Any hints? I haved tried to ask google without luck. The idea is to use an UDP broadcast to discover all devices, and a similar UDP broadcast to configure the devices. In the latter the MAC will be the key to address individual devices. As we are talking less than 100 devices this looks quite doable. But I do not want to invent something again if it already exists. Thanks in advance for any inputs, Sam -- 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: Remote IP setup of devices in a network
On Tue, Nov 08, 2011 at 07:11:09PM +, David Woodhouse wrote: On Tue, 2011-11-08 at 19:54 +0100, Sam Ravnborg wrote: The idea is to use an UDP broadcast to discover all devices, and a similar UDP broadcast to configure the devices. In the latter the MAC will be the key to address individual devices. You could almost be describing link-local IPv6. Each device automatically gets an IPv6 address based on its MAC address, which you can use for unicast addressing. The broadcast (or multicast) bit is easy enough too. We are forced to use a IPv4 network where we need to keep the devices in the same network as a potential router. So to describe the idea with a little drawing: Host PCDevice-1 Device-2 | || | DISCOVER-|---| | || |-- REPLY(MAC:IP)--|| |-- REPLY(MAC:IP)---| | || (technician manually decide IP setup) | || |-- CONFIG(MAC:IP)-|| |-- CONFIG(MAC:IP)--| The discover is maybe sent twice due to packer drops. The Reply is sent once and may look like this: MAC=01:02:03:04:05:06;IP=10.11.12.13;NM=255.0.0.0;GW=10.0.0.1;XX=foo bar;YY=baz buz The technician then decides the new config (or computer assisted). And the CONFIG may look like this: MAC=01:02:03:04:05:06;IP=192.168.0.201;NM=255.255.255.0;GW=192.168.0.1 I cannot get this with auto-IP or wahtever it is named for IPv4. Sam -- 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: debugging multi threaded applicatiosn on arm - status?
Is it possible to bebug multi-threaded applications using gdb on ARM these days? It works for me, using various ARM 926 and Cortex A8 chips and kernel versions from 2.6.27 to the present day. Which version of gbd do you have? gdb version 7.x works much better than 6.x in my experience. We are using 6.8 - which may be the culprint. Does it work with NPTL too? Sam -- 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 5/5] KBUS source file
On Mon, Feb 28, 2011 at 10:25:41PM +, Tony Ibbs wrote: On 28 Feb 2011, at 19:23, Sam Ravnborg wrote: You are using /proc/* to something that is not process related. At lkml you will be requested to use something else. OK. That's mainly through ignorance of what I *should* be using instead (and perhaps poor reading of Linux Device Drivers). Do you have an opinion on where such information should be going? I think sysfs is the better place. But my experience in this ares is limited. If there is a better way for me to submit this, please let me know. One way you would not like Let the first patches introduce core-functionality and add features in later patches - touching the same file many times. Hmm. That's very sensible. Assuming I can figure out a sensible way to do it (which I assume is what you expected me to object). It is a lot of work when you already have something that works. But sometimes it helps to do so. I have previously done a complete rewrite in the process (becuase my initial version was bad). Sam -- 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: [RFC][PATCH] KBUS messaging subsystem
[Edited cc: list as my smtp server refused to send the original reply] Our tentative patch is at http://kbus.googlecode.com/files/0001-KBUS-messaging-subsystem.patch The diffstat for the patch is: Documentation/Kbus.txt | 1189 ++ include/linux/kbus_defns.h | 666 ++ init/Kconfig |3 + ipc/Kconfig| 99 + ipc/Makefile |1 + ipc/kbus.c | 5120 ipc/kbus_internal.h| 773 +++ 7 files changed, 7851 insertions(+), 0 deletions(-) Should I just submit the patch to this list? You will get more feedback on lkml... Looks like comprehensive descriptions - good! Took a quick peek at the patch. - use __u32 (and friends) in exported headers - not uint32_t. - do not invent our own logging system. Use one of the standard methods. If you post for review try to divide it up a little. Maybe kbus.c in one patch, Makefile + Kconfig in last patch. It is a large file to review already. Sam -- 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: How to create a git repo on git.kernel.org?
On Mon, Oct 19, 2009 at 03:40:44PM -0500, Bill Gatliff wrote: Guys: How does one go about creating a git tree on git.kernel.org? I'd like to create one there as a public repository for the PWM API stuff, and for a couple of boards that I'd like to get into mainline. Step one is to get an account on kernel.org. Try to send an email to ftpad...@kernel.org and explain why you think you need an account / git tree there. You will have to PGP sign your mail and having someone to recommend you will help. Sam -- 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 4/6] Add support for LZO-compressed kernels for ARM
On Fri, Aug 07, 2009 at 09:00:01PM +0100, Russell King - ARM Linux wrote: On Fri, Aug 07, 2009 at 03:55:24PM +0200, Albin Tonnerre wrote: That's true for the actual kernel image, but not for the bootstrap code we use when compiling compressed kernels. arch/arm/boot/compressed/Makefile uses libgcc, unless I'm overlooking something here: arm-unknown-linux-uclibcgnueabi-ld -EL--defsym zreladdr=0x20008000 --defsym initrd_phys=0x2041 --defsym params_phys=0x2100 -p --no-undefined -X /home/albin/x-tools/arm-unknown-linux-uclibcgnueabi/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.3.2/libgcc.a -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.gzip.o arch/arm/boot/compressed/misc.o -o arch/arm/boot/compressed/vmlinux It's because libgcc appears in the wrong place in the command line, and due to the way kbuild works, we can't get it into the right place easily. Linkers are sensitive to the order of archives on the command line - its pointless having an archive as the first file argument because none of the contained objects will ever be pulled in. Sam - any ideas how to solve this? We could add libgcc as a prerequisite. Untested patch below. This is a ittle hackish - otherwise we have to change the definition of ld or use a private version. I added explanations for some of the linker symbols when I was there. I cannot the ld options. If you decide to use this it has my: Signed-off-by: Sam Ravnborg s...@ravnborg.org Sam diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile index ce39dc5..4f980f2 100644 --- a/arch/arm/boot/compressed/Makefile +++ b/arch/arm/boot/compressed/Makefile @@ -87,15 +87,24 @@ endif ifneq ($(PARAMS_PHYS),) LDFLAGS_vmlinux += --defsym params_phys=$(PARAMS_PHYS) endif -LDFLAGS_vmlinux += -p --no-undefined -X \ - $(shell $(CC) $(KBUILD_CFLAGS) --print-libgcc-file-name) -T + +# ? +LDFLAGS_vmlinux += -p +# Report unresolved symbol references +LDFLAGS_vmlinux += --no-undefined +# Delete all temporary local symbols +LDFLAGS_vmlinux += -X +# Next argument is a linker script +LDFLAGS_vmlinux += -T + +libgcc = $(shell $(CC) $(KBUILD_CFLAGS) --print-libgcc-file-name) # Don't allow any static data in misc.o, which # would otherwise mess up our GOT table CFLAGS_misc.o := -Dstatic= $(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o \ - $(addprefix $(obj)/, $(OBJS)) FORCE + $(addprefix $(obj)/, $(OBJS)) $(libgcc) FORCE $(call if_changed,ld) @: Sam -- 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 5/5] Add support for LZO-compressed kernels on x86
On Fri, Jul 31, 2009 at 09:51:19AM +0200, Albin Tonnerre wrote: On Wed, Jul 29, 2009 at 11:02:58PM +0200, Sam Ravnborg wrote : On Wed, Jul 29, 2009 at 01:00:36PM -0700, H. Peter Anvin wrote: On 07/22/2009 07:01 AM, Albin Tonnerre wrote: This is the third and last part of the patch, which contains the necessary changes to the x86 Kconfig and boot/compressed to allow the use of this new compression method Signed-off-by: Albin Tonnerre albin.tonne...@free-electrons.com Acked-by: H. Peter Anvin h...@zytor.com Since the patchset otherwise isn't really x86-related it probably makes more sense to pass this through the kbuild tree, or perhaps via akpm, rather than -tip? I can take it via kbuild if I get a fewsh patch-set with proper ack's added. I've long lost the original patch-set. Only the x86-specific part of the patch has been acked so far, and it relies on 3 other patches which have not been acked. If there's anything I can do to get feedback on the remaining patches, please let me know. Please resend the full serie then I may take a short look at it. Sam -- 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 5/5] Add support for LZO-compressed kernels on x86
On Wed, Jul 29, 2009 at 01:00:36PM -0700, H. Peter Anvin wrote: On 07/22/2009 07:01 AM, Albin Tonnerre wrote: This is the third and last part of the patch, which contains the necessary changes to the x86 Kconfig and boot/compressed to allow the use of this new compression method Signed-off-by: Albin Tonnerre albin.tonne...@free-electrons.com Acked-by: H. Peter Anvin h...@zytor.com Since the patchset otherwise isn't really x86-related it probably makes more sense to pass this through the kbuild tree, or perhaps via akpm, rather than -tip? I can take it via kbuild if I get a fewsh patch-set with proper ack's added. I've long lost the original patch-set. Sam -- 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 06/14] Pramfs: Include files
On Mon, Jun 22, 2009 at 08:31:10PM +0100, Chris Simmonds wrote: Arnd Bergmann wrote: On Monday 22 June 2009, Marco wrote: Sorry, I meant it's not currently possible. At the moment the only way to use it as rootfs it's to copy all the data in an already mounted (empty) ram partition and reboot. However it's not my first item on my todo list because I think that it's possible to use it as rootfs but it isn't the standard use for this fs. Well, it doesn't have to work right away. What I'm asking to define the data structures in a way that keeps the layout stable across kernel updates. Since a future version of the file system might support cross-endian image creation, it would be good to define the data structures in a fixed endian mode already, so you don't have to change it in the future. Arnd -- 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 I disagree: that adds an unnecessary overhead for those architectures where the cpu byte order does not match the data structure ordering. It is not that we are talking big and complex stuff here. pramfs is likely to be used for small things and then having to fix endian on a few headers in the on-dsk format does not matter. Not compared to the potential disadvantages. It should be possible to read a file-system on your x86 64bit box that you wrote with your small powerpc target. Sam -- 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 06/14] Pramfs: Include files
It should be possible to read a file-system on your x86 64bit box that you wrote with your small powerpc target. For a (NV)RAM-based filesystem?? WTH??? dd the full image - dig into it. Usefull is you have post-mortem info there. Sam -- 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 06/14] Pramfs: Include files
On Sat, Jun 13, 2009 at 03:21:48PM +0200, Marco wrote:
From: Marco Stornelli marco.storne...@gmail.com
Include files.
Signed-off-by: Marco Stornelli marco.storne...@gmail.com
---
diff -uprN linux-2.6.30-orig/fs/pramfs/pram_fs.h
linux-2.6.30/fs/pramfs/pram_fs.h
--- linux-2.6.30-orig/fs/pramfs/pram_fs.h 1970-01-01 01:00:00.0
+0100
+++ linux-2.6.30/fs/pramfs/pram_fs.h 2009-06-13 12:58:49.0 +0200
@@ -0,0 +1,388 @@
+/*
+ * FILE NAME include/linux/pram_fs.h
+ *
+ * BRIEF DESCRIPTION
+ *
+ * Definitions for the PRAMFS filesystem.
+ *
+ * Copyright 2009 Marco Stornelli marco.storne...@gmail.com
+ * Copyright 2003 Sony Corporation
+ * Copyright 2003 Matsushita Electric Industrial Co., Ltd.
+ * 2003-2004 (c) MontaVista Software, Inc. , Steve Longerbeam
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+#ifndef _LINUX_PRAM_FS_H
+#define _LINUX_PRAM_FS_H
+
+#include linux/types.h
+
+#ifdef __KERNEL__
+#include linux/sched.h
+#include linux/buffer_head.h
+#include pram_fs_sb.h
+#endif
The only reason to have this header file in include/linux/
is that it is used by userspace.
So please split it up so we have one header suitable for exporting
and another header with all the promfs local stuff.
The latter should be in fs/pramsfs/
+
+/*
+ * The PRAM filesystem constants/structures
+ */
+
+/*
+ * Define PRAMFS_DEBUG to produce debug messages
+ */
+#define PRAMFS_DEBUG
+
+/*
+ * Debug code
+ */
+#ifdef __KERNEL__
+#define PFX pramfs
+#ifdef PRAMFS_DEBUG
+#define pram_dbg(format, arg...) \
+printk(KERN_DEBUG PFX : format , ## arg)
+#else
+#define pram_dbg(format, arg...) do {} while (0)
+#endif
+#define pram_err(format, arg...) \
+printk(KERN_ERR PFX : format , ## arg)
+#define pram_info(format, arg...) \
+printk(KERN_INFO PFX : format , ## arg)
+#define pram_warn(format, arg...) \
+printk(KERN_WARNING PFX : format , ## arg)
+#endif
For a typical drivers we have some pr_* to avoid the above.
Can they be used for a filesystem too?
+
+/*
+ * The PRAM file system magic number
+ */
+#define PRAM_SUPER_MAGIC 0xEFFA
Move to include/linux/magic.h
+
+/*
+ * Structure of an inode in PRAMFS
+ */
+struct pram_inode {
+ __u32 i_sum; /* checksum of this inode */
+ __u32 i_uid; /* Owner Uid */
+ __u32 i_gid; /* Group Id */
+ __u16 i_mode; /* File mode */
+ __u16 i_links_count; /* Links count */
+ __u32 i_blocks; /* Blocks count */
+ __u32 i_size; /* Size of data in bytes */
+ __u32 i_atime;/* Access time */
+ __u32 i_ctime;/* Creation time */
+ __u32 i_mtime;/* Modification time */
+ __u32 i_dtime;/* Deletion Time */
+
+ union {
+ struct {
+ /*
+ * ptr to row block of 2D block pointer array,
+ * file block #'s 0 to (blocksize/4)^2 - 1.
+ */
+ off_t row_block;
It is my understanding that we shall use: __kernel_off_t
in exported headers.
The headers are not added to Kbuild - so it is not exported.
I assume thats an oversight.
Sam
--
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 [0/3]: Simplify the kernel build by removing perl.
On Sun, Jan 11, 2009 at 11:50:31PM -0600, Mark A. Miller wrote: On Sun, Jan 11, 2009 at 11:35 PM, Sam Ravnborg s...@ravnborg.org wrote: There are several other packages which are broken for embedded architectures, which I will hopefully attempt to fix by submitting patches upstream. But this is why we should be cautious about including new tools for compiling the kernel. Sam Ravnborg was correct in that a C program to do the work would be the proper way. But by not addressing a currently existing problem with an adequate replacement with something that does not exist currently, seems faulty. Why are make headers_install such a crucial thing for your embedded environmnet? Sanity check. If the environment cannot replicate itself, then something has been faulty in the cross-compiling stage, that was used to propagate a native environment for the target architecture. So you actually build your target toolchain on your target? Sam -- 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 [0/3]: Simplify the kernel build by removing perl.
There are several other packages which are broken for embedded architectures, which I will hopefully attempt to fix by submitting patches upstream. But this is why we should be cautious about including new tools for compiling the kernel. Sam Ravnborg was correct in that a C program to do the work would be the proper way. But by not addressing a currently existing problem with an adequate replacement with something that does not exist currently, seems faulty. Why are make headers_install such a crucial thing for your embedded environmnet? I would assume that if this of such improtance then there is also someone to step up and contribute a C version of it. Sam -- 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 [0/3]: Simplify the kernel build by removing perl.
On Sat, Jan 03, 2009 at 07:45:34PM -0600, Rob Landley wrote: With respect to your three patches the plan is to: - add the updated timeconst patch to kbuild-next - add the updated cpu-feature patch to kbuild-next - the patch touching headers_install will not be merged. The way forward for headers_install is to combine the unifdef feature and the header modifications. Since you're turning down an existing patch in favor of a theoretical patch, I assume you have plans to do this yourself? If noone else beats me I will do so - yes. And this must be in a single program that can process all headers in one go so the install process becomes so fast that we do not worry about if it was done before or not. Then we can avoid all the .* files in the directory where we isntall the headers. What if they run out of disk space halfway through writing a file and thus it creates a short file (or a 0 length file where the dentry was created but no blocks could be allocated for the write)? Then they fail and make will know. Then may leave a file or 100 but it still failed. At next run everything will be done right assuming the culprint has been fixed. I can try to make the shell version more readable, and more powerful. It's already noticeably faster than the perl version. I have no objections to making unifdef do all of this, I just haven't got any interest either. I have no interest in merging a shell version. I clearly expressed above that we need a _single_ program doing all of the preparations and we do not need a reimplmentatio of the current headers_install. I also explained why. Sam -- 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 [0/3]: Simplify the kernel build by removing perl.
Hi Wookey. Given the simplicitly of these patches I can't see any reason not to put them in Please do NOT do the mistake and think this the same thing. Rob's patch simplyfy the timecost stuff - and will be applied on this merit alone assuming comments will be addressed. But the serie rased anohter topic: shall we ban use of perl for generating a kernel. And this is what primary is discussed and the outcome of that discussion will not prevent patches that stands on their own to be applied. Sam -- 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: LZMA inclusion
On Wed, Dec 03, 2008 at 08:58:52PM +0100, Bernhard Reutner-Fischer wrote: On Wed, Dec 03, 2008 at 11:36:45AM -0800, Tim Bird wrote: Gregers Petersen wrote: There was a small talk a few days ago involving a few of the OpenWrt developers and David Woodhouse. One of the topics discussed, was a question about the potential of including LZMA in the kernel. Such an inclusion would be quite benefitial in terms of embedded systems, but the major hurdle seems to be the code quality of LZMA itself. This leads to the question I would like to raise; are there ongoing plans (or considerations) to rewrite and merge LZMA, and has anyone started working on it in practical terms? Did anyone answer this? CELF is currently considering funding a project to do this (add LZMA support to the kernel), and it would be good to get a feel for the current status... -- Tim AFAIK xz will be/is incompatible with this older LZMA, perhaps larhzu wants to chime in on that. PS: A previous incarnation of that patch didn't work conventiently for me, i had to do some small adjustments to the way it was put into the kernel configury, like http://repo.or.cz/w/buildroot.git?a=blob_plain;f=toolchain/kernel-headers/lzma/linux-2.6.22.1-002-lzma-vmlinuz.01.patch;hb=HEAD http://repo.or.cz/w/buildroot.git?a=blob_plain;f=toolchain/kernel-headers/lzma/linux-2.6.22.1-003-lzma-vmlinuz.patch;hb=HEAD If these are required with latest kernel could I then ask you to properly submit them to: [EMAIL PROTECTED] No need to have good patches sitting at random places. Sam -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LZMA inclusion
PS: Not sure if you, Sam, are the right person who cares for it, but
i think that the help-text and actual accepted arguments of
scripts/kconfig/lxdialog/check-lxdialog.sh are out of sync.
I queued up the following:
From f6682f915760ccfe57ef1b6cd5ff2d8f2bf8c1d4 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg [EMAIL PROTECTED]
Date: Wed, 3 Dec 2008 22:11:14 +0100
Subject: [PATCH] kconfig: fix options to check-lxdialog.sh
As noted by Bernhard - fix it up.
Cc: Bernhard Reutner-Fischer [EMAIL PROTECTED]
Signed-off-by: Sam Ravnborg [EMAIL PROTECTED]
---
scripts/kconfig/lxdialog/check-lxdialog.sh |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/kconfig/lxdialog/check-lxdialog.sh
b/scripts/kconfig/lxdialog/check-lxdialog.sh
index 5552154..fcef0f5 100644
--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
@@ -52,7 +52,7 @@ EOF
}
usage() {
- printf Usage: $0 [-check compiler options|-header|-library]\n
+ printf Usage: $0 [-check compiler options|-ccflags|-ldflags compiler
options]\n
}
if [ $# -eq 0 ]; then
PPS: I did not verify if this is still the case, but I have this
comment as a reminder for a small issue with archprepare versus
headers_install, fwiw. It would be very handy if i could fuse those
two into a simple make ... archprepare headers_install:
Which architectures needs this archprepare?
It would be good to get rid of the dependency.
PS. I consider archprepare an internal target.
If some preparation is needed the recommended target is 'prepare'.
The day no targets has any special things they need to do archprepare will die.
Sam
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LZMA inclusion
two into a simple make ... archprepare headers_install: Which architectures needs this archprepare? At least cris tripped this IIRC, at least before or around the time when cris's subarch handling was fixed (the asm-cris/arch-v10 vs. arch-v32 linking issue). It would be good to get rid of the dependency. nod PS. I consider archprepare an internal target. If some preparation is needed the recommended target is 'prepare'. The day no targets has any special things they need to do archprepare will die. The proper solution would perhaps be to do have prepare or archprepare as a prerequisite of headers_install as long as those are needed, i guess. We need to run as little arch specific stuff as possible for headers_install so adding this prerequisite would just hide the real issue that the arch has some latent bug to be fixed. For cris we fixed it when we moved the headers (Jesper did - I was not involved). So if you could check it out and see if other archs need it I would be glad. If there are others I will try to get these fixed so they do not need archprepare for headers_isntall. Sam -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
On Wed, Nov 26, 2008 at 12:51:27AM -0500, Jaya Kumar wrote: On Tue, Nov 25, 2008 at 11:15 PM, David Brownell [EMAIL PROTECTED] wrote: On Tuesday 25 November 2008, Eric Miao wrote: Using a bit mask will be more generic if the GPIOs are not contiguous. Yet I still doubt this will be generic enough to be added to gpiolib. My expectation for this kind of mechanism was that systems who need to craft another parallel bus out of GPIO pins would be doing this with some system-specific utility functions. So my is it generic enough question is more at the level of Are there enough Linux systems that need this sort of thing to justify generic support?. I happen not to have come across the need for such ganged access from Linux (yet). Whereas I've yet to use non-x86 Linux systems that don't need to manipulate individual GPIO pins... I have come across the following scenarios where a bus set of gpio is useful: - Broadsheet E-Ink controller (uses 16-bit data bus over GPIO) framebuffer device (this patch is for this) - Apollo/Hecuba E-Ink controller (uses 8-bit data bus over GPIO) framebuffer device - 8-bit parallel IO matrix LCD controllers, such as the Samsung KS108, also Hitachi, etc We have such a system at work. And we need fast acces to the gpio pins when updating the LCD. I have not written/looked to deep at the code I just recall it was a bit messy and not something I would be proud of submitting to any ML. Sam -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
On Fri, Nov 28, 2008 at 07:43:31AM +0800, Jaya Kumar wrote: On Fri, Nov 28, 2008 at 4:01 AM, Sam Ravnborg [EMAIL PROTECTED] wrote: On Wed, Nov 26, 2008 at 12:51:27AM -0500, Jaya Kumar wrote: On Tue, Nov 25, 2008 at 11:15 PM, David Brownell [EMAIL PROTECTED] wrote: On Tuesday 25 November 2008, Eric Miao wrote: Using a bit mask will be more generic if the GPIOs are not contiguous. Yet I still doubt this will be generic enough to be added to gpiolib. My expectation for this kind of mechanism was that systems who need to craft another parallel bus out of GPIO pins would be doing this with some system-specific utility functions. So my is it generic enough question is more at the level of Are there enough Linux systems that need this sort of thing to justify generic support?. I happen not to have come across the need for such ganged access from Linux (yet). Whereas I've yet to use non-x86 Linux systems that don't need to manipulate individual GPIO pins... I have come across the following scenarios where a bus set of gpio is useful: - Broadsheet E-Ink controller (uses 16-bit data bus over GPIO) framebuffer device (this patch is for this) - Apollo/Hecuba E-Ink controller (uses 8-bit data bus over GPIO) framebuffer device - 8-bit parallel IO matrix LCD controllers, such as the Samsung KS108, also Hitachi, etc We have such a system at work. And we need fast acces to the gpio pins when updating the LCD. I have not written/looked to deep at the code I just recall it was a bit messy and not something I would be proud of submitting to any ML. Sam Okay. Please help me understand in case I misunderstood. Are you saying the code that I posted is too messy? To me, actually I am proud of it. :-) But if some parts look messy, I'm happy to work on improving it. I will need some advice though and please advise me on which parts look messy. Nope - the code we use at work is too messy. What you posted looks much better. Sam -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add diffconfig utility (v2)
On Tue, Jun 24, 2008 at 10:56:06AM -0700, Tim Bird wrote: Sam Ravnborg wrote: When you consider it stabilized could you please drop me a new mail including full changelog and updated patch. And please cc: [EMAIL PROTECTED] + linux-kernel on the submission. Sam, I haven't gotten any more feedback, and I believe I've addressed all previous feedback. Thanks, applied Sam -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] Embedded Maintainer(s), [EMAIL PROTECTED] list
On Mon, Jun 23, 2008 at 07:22:10PM +0200, Denys Vlasenko wrote: On Wednesday 30 April 2008 21:11, David Woodhouse wrote: On Wed, 2008-04-30 at 20:22 +0200, Andi Kleen wrote: David Woodhouse [EMAIL PROTECTED] writes: Andrew Morton has been saying recently that we need an 'embedded maintainer', to take responsibility for 'embedded issues' in the core kernel, as well as trying to improve our relationship with those using the Linux kernel for 'embedded' devices -- who have a reputation of not working with us very closely; to their detriment as well as our own. I hope your job description doesn't include adding more and more CONFIGs though. I am sure there are lots of low hanging fruit where memory can be saved and it's a good thing someone cares about that, but please don't focus on the code size only. Or if you work on that don't do it using CONFIG or when you really add a new one find some other that is pointless and remove it first. There are simply already far too many of them and they make the kernel harder and harder to change. I agree. And if we do want to pay attention to pure code size, there are other approaches -- like --gc-sections I have some patches in this area too. Were submitted to Sam but he was too busy it seems. They were not trivial to apply and so went down on the TODO list. We could try to push the generic and x86 specific .lds stuff via the arch maintainers? Sam -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] Embedded Maintainer(s), [EMAIL PROTECTED] list
On Mon, Jun 23, 2008 at 09:12:30PM +0200, Denys Vlasenko wrote: On Monday 23 June 2008 20:57, Sam Ravnborg wrote: I agree. And if we do want to pay attention to pure code size, there are other approaches -- like --gc-sections I have some patches in this area too. Were submitted to Sam but he was too busy it seems. They were not trivial to apply and so went down on the TODO list. I realize that they were not trivial to review, but that was unavoidable. They were even more not trivial to create. We could try to push the generic and x86 specific .lds stuff via the arch maintainers? IIRC I splitted the entire GC collection patch in a way that first patches were doing exactly this easier first part and I hoped that at least these first patches will be taken. They were big, but somewhat trivial, from it's obviously safe department. I do not recall anything wrong with the patch-set. Had they been applied, now making --gc-sections to work would be easier. Agreed. I should have asked you to push this via arch maintainers back then. Sam -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add diffconfig utility
Hi Tim. The program is also now better structured, IMHO. -- Tim Seeing this programs gets frequent updates (good!) I have not yet applied it. When you consider it stabilized could you please drop me a new mail including full changelog and updated patch. And please cc: [EMAIL PROTECTED] + linux-kernel on the submission. Thanks, Sam -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mainlining min-configs...
On Wed, Jun 11, 2008 at 12:09:56PM -0700, Tim Bird wrote: Sam Ravnborg wrote: When I get my kconfig patchset polished you will be able to do: make K=my_mini_config allnoconfig So you're renaming KCONFIG_ALLNOCONFIG then? Somehow yes. The K= notation I hope will see more use. Only very few people know the KCONFIG_ALL*CONFIG= trick. Indeed. I had never heard of it, but it appears to have been around for at least 18 months. It looks like Randy Dunlap tried to submit some documentation for this in Oct 2006, but it didn't make it in? Is this feature widely used? Should it be doc'ed now or are you about to make it obsolete? I will most likely obsolete all except KCONFIG_ALLCONFIG And I'm afraid I have Randy patch somewhere. Sam -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] console - Add configurable support for console charset translation
I can do a more controlled comparison if you're interested. What would be really useful would be to do some king of automated monitoring of the size of individual parts of the kernel in a few controlled configs. And then as son as somethings grows with 1% for example then to bring this to lkml. Doing this based on linux-next would allow us to catch the bloaters while they are still or just have been doing certain changes. It would be nice to tell someone that just enabled som new gcc option that this had a cost of 163.432 bytes with a certain config. This would get attraction and be dealt with. Doing so three months later or maybe one year later would often get less focus (if the individual commit ever got identified). Now how to do so I dunno - that would require a bit of tweaking before working reliable. But the value of being quick here would pay of this soon I think. Sam -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
