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: Can I manage/modify console baud rates from userspace?
On Sun, May 02, 2010 at 12:14:55PM -0400, Paul Smith wrote: > On Sun, 2010-05-02 at 11:58 +0200, Marco Stornelli wrote: > > 02/05/2010 02:02, Paul Smith wrote: > > > I've looked at setserial and it supports a baud_base parameter but that > > > doesn't appear to be what I want (I tried it anyway: changing it didn't > > > work, my console output was still screwed up). > > > > > > Trying to do something like creating customized PXE configs on the > > > server based on the MAC addresses of the blades that are "new" (or old) > > > would be an absolute nightmare as people swap blades between chassis, > > > add new ones, etc. all the time. > > > > > > > > > Please help me find a better way... :-( > > > > > > > It's strange that it's not possible to change the baud rate, but I'm not > > an expert of tty layer. A naive implementation could be patch the kernel > > to choose a well-known baud rate for your hw reading a revision register > > or something like that. > > I guess; I'd hate to have to modify the kernel like that though. Plus, > as far as I'm aware at the moment the only way to tell these blades > apart is through querying IPMI which would be a serious bummer to try to > do via the kernel, I believe. Maybe there's some other way to do it > that's simpler. > > Still hoping someone will say "all you have to do is XYZZY..." Anyone? I would suggest asking Alan Cox - he if anyone would know. I lost the original mail and context above is missing some details. Anyway added to this mail. 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: [PATCH 5/5] KBUS source file
On Sun, Feb 27, 2011 at 07:26:49PM +, Tony Ibbs wrote: > Apologies, my fifth patch (the actual KBUS source file) appears to be > too long - I hadn't realise the 100,000 character limit on majordomo > messages. The file as submitted is that at: > > > https://github.com/crazyscot/linux-2.6-kbus/blob/6cc3262bd3e28757179dd8a0d30298dfb2f70845/ipc/kbus.c You are using /proc/* to something that is not process related. At lkml you will be requested to use something else. You can conisder splitting this up in another file so you in the Makefile can use it conditionally. > 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. Also please submit the Makefile/Kconfig stuff in the _last_ mail. Otherwise you would ruin bisect because we cannot build kbus until you have the last files included. 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
debugging multi threaded applicatiosn on arm - status?
Is it possible to bebug multi-threaded applications using gdb on ARM these days? We have had trobules getting this to work - but I do not have the details at hand atm. I am just curious if this is supposed to work or not. We have an arm target running: 2.6.32.8 #1 PREEMPT CPU: ARM926EJ-S rev 5 (v5l) (Atmel AT91SAM9263) The kernel is only lightly modifed - mostly with a few propriatary drivers and a few driver hacks (not suitable for mainline). It is a long story why we use such an old version. Our applications uses threads and we use glibc 2.10.1 with NPTL enabled. So far we have survived using the powerfull printf debugging :-) 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
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: [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
Re: [PATCH 0/1] Embedded Maintainer(s), [EMAIL PROTECTED] list
On Mon, Jun 09, 2008 at 10:53:11PM -0500, Rob Landley wrote: > On Monday 09 June 2008 16:27:29 Leon Woestenberg wrote: > > > I submitted a patch to remove the use of perl to build the linux kernel > > > (which HPA added in 2.6.25) not because it affected the result, but > > > because it unnecessarily complicates the build system. (And perl tends > > > to metasticize. > > > > Thanks, I hope it is or gets accepted. > > Nope, Peter Anvin shot it down (saying what I was doing was a strange, purely > academic exercise), and Sam Ravnborg announced his vague intention to rewrite > large chunks of kbuild in perl in the future. (Because nothing > says "maintainability" like perl...) > > For some reason they wanted to mail me about it off-list rather than cc:ing > the list about this plan. Rob - please reread the mails. It was your broken mailer or something that caused it to be off-list. When I hit reply-to-all in mutt I expect it to be sent to the list - and in your case it did not not hit the list. > > A number of embedded people emailed me about it off list, but nobody ever > replied to my post _on_ the list to say I wasn't alone in this, or acked the > patch to say it worked for them, or anything like that. So there was a > perception of zero support, and I gave up trying to follow up on it for > 2.6.25. I've got it working for me, and if more perl shows up I'll come up > with more patches to remove it for my own personal build environment. > > I might try to submit again in a few months Then please try to address the comments first. 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
> (Maybe I _am_ the only person who still cares about > building on a host without perl. If I wasn't, somebody else would have acked > the patch...) perl is pretty standard and I fail to see the benefits of avoiding it. For embedded development I see even less benefits as I assume any sane embedded development environment are based on a cross-toolchain so you do the build on a high perfomance box. Building everything for my arm board on the arm board would be a disater for example. 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
> > When did this policy change, so that it's now acceptable to depend on > Perl, which is roughly equivalent as a tool dependency? We have perl as a mandatory part of the kernel build in several places for various architectures. And I do not recall anyone submitting a bug that they could not build a kernel due to the perl dependency. But I am obviously well aware of that we use it for the time stuff. For the headers_* targets I will shortly introduce yet another perl dependency - but only if these targets are used - so less of an issue. o We shall try to keep the dependencies low for the common things o but for the more exoctic things a wides dependency is OK. Which is also why I'm happy to apply a patch that remove the mandatory dependency of perl we have today - if and only if that patch meet normal patch acceptance criterias. Rob's initial patch had some issues and neither Rob nor I have fixed these and therefore it has not been applied. Rob seems to put much more into this (private reply accustions etc) for reasons unknown to me. And doing so does not help to get me interested. So try to get the facts correct here - there is noone against removing the mandatory perl dependency. But it is lower on my priority list than many other things which explain why I do not do it myself. But if someone submit a patch to do so then if the patch is OK it will be applied. And if we have a policy that say no-go to perl then it is new to me. I hope one day to rewrite part of kbuild and perl seems to be the best candidate around. But that day may never come. 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 Tue, Jun 10, 2008 at 09:30:04PM +0300, Adrian Bunk wrote: > On Tue, Jun 10, 2008 at 11:18:30AM -0700, Tim Bird wrote: > > Adrian Bunk wrote: > >... > > > You need both, and ideally constantly done by the same person against > > > Linus' tree, -next and -mm. > > > > > > Where to get your minimal configs from at the start is just a small > > > thing at the beginning - don't underestimate the required manual work > > > that will have to be done each week. > > > > This is probably why I haven't signed up for this myself previously. > > I'd be interested in finding out the rate at which defconfigs > > bitrot in mainline. My experience is that usually a 'make oldconfig' > > will produce something usable. But maybe that wouldn't be as > > effective with a minconfig? > >... > > Someone has to run the 'make oldconfig' for all configs... > > And no, you cannot get that completely automated. When I get my kconfig patchset polished you will be able to do: make K=my_mini_config allnoconfig Thus selecting 'no' for all new symbols in an automated fashion. I know that in a few cases 'no' is the wrong answer but in the 99% of the cases 'no' is perfectly valid. 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
On Tue, Jun 10, 2008 at 11:02:18PM +0200, Jörn Engel wrote: > On Tue, 10 June 2008 12:41:54 -0700, Tim Bird wrote: > > Delivery-date: Tue, 10 Jun 2008 21:44:08 +0200 > > From: Tim Bird <[EMAIL PROTECTED]> > > To: linux-embedded > > CC: linux kernel <[EMAIL PROTECTED]> > > Subject: [PATCH] add diffconfig utility > > Neat. But I have one nagging question: who do you expect to merge this > patch? ;) I will merge it if the feedabck is positive and eventual feedback is dealt with. (And Tim reminds me to do so in a week or so). I take most of the random scripts in scripts/ via kbuild.git. 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
On Tue, Jun 10, 2008 at 12:41:54PM -0700, Tim Bird wrote:
> diffconfig is a simple utility for comparing two .config files.
> Using standard diff to compare .config files often includes
> extraneous and distracting information. This utility produces
> sorted output with only the changes in configuration values
> between the two files.
>
> I have found this handy for use in testing to
> detect when option dependencies unexpectedly affect
> other options.
>
> To use, apply the patch and 'chmod a+x scripts/diffconfig'
>
> Signed-off-by: Tim Bird <[EMAIL PROTECTED]>
>
> diffconfig | 90
> +
> 1 files changed, 90 insertions(+)
>
> --- linux-2.6.24.orig/scripts/diffconfig 1969-12-31 16:00:00.0
> -0800
> +++ test-linux/scripts/diffconfig 2008-06-10 12:11:14.0 -0700
> @@ -0,0 +1,90 @@
> +#!/usr/bin/python
> +#
> +# diffconfig - a tool to compare .config files.
> +#
> +# originally written in 2006 by Matt Mackall
> +# (at least, this was in his bloatwatch source code)
> +#
> +# diffconfig is a simple utility for comparing two .config files.
> +# Using standard diff to compare .config files often includes
> +# extraneous and distracting information. This utility produces
> +# sorted output with only the changes in configuration values
> +# between the two files.
> +#
> +# Added and removed items are shown with a leading plus or minus,
> +# respectively. Changed items show the old and new values on a
> +# single line.
> +#
> +# Example usage:
> +# $ diffconfig .config config-test-nfs-off
> +# -LOCKD y
> +# -LOCKD_V4 y
> +# -NFS_COMMON y
> +# -NFS_DIRECTIO n
> +# -NFS_V3 y
> +# -NFS_V3_ACL n
> +# -NFS_V4 n
> +# -ROOT_NFS y
> +# -RPCSEC_GSS_KRB5 n
> +# -RPCSEC_GSS_SPKM3 n
> +# -SUNRPC y
> +# -SUNRPC_BIND34 n
> +# NFS_FS y -> n
> +
> +import sys, os
> +
> +if len(sys.argv) < 3:
> + print "Usage: diffconfig "
> + sys.exit(0)
I know this is unix style to be very short in usage - but then they
have man pages.
Could we add a bit more from the nice description above to usage?
> +
> +# returns a dictionary of name/value pairs for config items in the file
> +def readconfig(config_file):
> +d = {}
> +for line in config_file:
> +line = line[:-1]
> +if line[:7] == "CONFIG_":
> +name, val = line[7:].split("=", 1)
> +d[name] = val
> +if line[-11:] == " is not set":
> +d[line[9:-11]] = "n"
> +return d
> +
> +a = readconfig(file(sys.argv[1]))
> +b = readconfig(file(sys.argv[2]))
> +
> +# print items in a but not b (accumulate, sort and print)
> +old = []
> +for config in a:
> +if config not in b:
> +old.append(config)
> +
> +old.sort()
> +
> +for config in old:
> +print "-%s %s" % (config, a[config])
> +del a[config]
> +
> +# print items that changed (accumulate, sort, and print)
> +changed = []
> +for config in a:
> +if a[config] != b[config]:
> +changed.append(config)
> +else:
> +del b[config]
> +
> +changed.sort()
> +
> +for config in changed:
> +print " %s %s -> %s" % (config, a[config], b[config])
> +del b[config]
> +
> +# now print items in b but not in a
> +
> +# the items from b that were in a (either the same or that changed) were
> removed
> +# the only items left were not in a
> +new = b.keys()
> +
> +new.sort()
> +
> +for config in new:
> +print "+%s %s" % (config, b[config])
No feedback on the implmentation - I do not speak phython.
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...
> > > > 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. > > > Thus selecting 'no' for all new symbols in an automated fashion. > > I know that in a few cases 'no' is the wrong answer but in the > > 99% of the cases 'no' is perfectly valid. > > For a "make miniconfig", warnings should be errors. (Attempts to set unknown > symbols are an error with a miniconfig, the operation should exit with a > nonzero error code.) Also, all the stuff allnoconfig puts to stdout > shouldn't be there for miniconfig, only the stuff it writes to stderr right > now should show up. My reference was to a minimal config of a system - not to a miniconfig as your patcset produces. Just to make it clear. The patchset I refer will also reduce the nosie generated during make *config. 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: mainlining min-configs...
On Wed, Jun 11, 2008 at 10:36:39PM +0300, Adrian Bunk wrote: > 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? > >... > > Randy's patch that documents KCONFIG_ALLCONFIG is in Linus' tree since > April 2006. The one I refer to is not. 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: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Thu, Jun 12, 2008 at 12:14:32PM -0500, Bill Gatliff wrote: > Paul Mundt wrote: > > > Yes, that's the easy case. It's things like perl that are the corner > > cases, and my objection comes from the fact that people think we ought to > > not have the kernel depend on perl rather than just fixing the package > > itself. Autoconf/libtool damage is an entirely different problem :-) > > > > At first glance, it seems like checkincludes.pl could be duplicated by egrep | > uniq | wc vs. egrep | wc. Not quite sure what checkversion.pl is trying to > do. > > The namespace.pl script looks optional, as does export_report.pl. > > So maybe we could _reduce_ dependency on perl, if there's any advantage to > gain > by doing so. But the kernel build machinery isn't dependent on very many > other > systems (just tcl, bash and gcc-core), so I don't really see the point unless > you could completely eliminate perl. And I don't see how you might do *that* > without dragging in a bunch of stuff to replace it, thereby increasing the > number of dependencies. All the noise about the perl dependency of the kernel build are rooted in two things: 1) That we now have a mandatory part of the build that uses perl (see kernel/Makefile) 2) That I told that I consider rewriting the core of the build system in perl As for 1) I have seen a patch submitted once. And I do not hear many complaint either, albeit Rob Landley is a bit loud here (and he was also the one submitting the patch). That patch was not acceptable as is - and noone has updated it. As for 2) then let see if that ever happens ;-) 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: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
> > Um, actually Eric Raymond and I have had long talks about this, and if we're > ever in the same state for more than 3 days we may finally get to do a > serious research project about the successors to ./configure and make. Tom has started a nice project which he named: quagmire. See: http://code.google.com/p/quagmire/ >From the website: quagmire is intended to replace automake and libtool. Unlike these tools it requires GNU make and is written solely using GNU make features -- no preprocessing is required. 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: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Fri, Jun 13, 2008 at 11:44:54AM -0700, Tim Bird wrote: > Bill Traynor wrote: > >>> Do you wanna set some breakpoints and inspect variables in makefiles? > >>> Have a look at a simple makefile debugger (written in make): > > http://www.embedded.com/columns/technicalinsights/197003517?printable=true > > The article above shows some macros you can add to your Makefile to show > you the values of certain things. It is helpful, but not an interactive > debugger. > > However, the guy who wrote that article did indeed write a full > Makefile debugger. I took it for a spin, and found that it worked as > advertised on a simple Makefile. I tried it on the kernel Makefile, but > without success (but I didn't try very hard). > > YMMV. I put some of the resources and info I found at: > http://elinux.org/Debugging_Makefiles > > The link from the package's README doesn't work, but here's a link > I found to an article about the debugger: > http://www.cmcrossroads.com/content/view/6479/120/ Quite impressive what he got out of the make features. The kernel does a few unusual tricks so I do understand why it does not work there. Speaking about the kernel... Try "make V=2" one day to see why a target are build. It is quite useful when a small change results in much more being build than you expected. But this is kernel specific and not a general feature. 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 (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: Incompatible CFLAGS for kernel module
On Fri, Jul 04, 2008 at 10:34:56PM +0500, Shaz wrote: > Hi, > > I am porting tpm emulator to versatilepb, which is an arm platform. I > have some problem with CFLAGS from /arch/arm/Makefile when building > the kernel module for this software. I cannot figure out what to do in > this case. Following is the error: > > [EMAIL PROTECTED] tpm_emulator-0.5]# make > Making all in tpmd > make[1]: Entering directory `/embedded/tpm_emulator-0.5/tpmd' > make[1]: Nothing to be done for `all'. > make[1]: Leaving directory `/embedded/tpm_emulator-0.5/tpmd' > Making all in tpmd_dev > make[1]: Entering directory `/embedded/tpm_emulator-0.5/tpmd_dev' > CC [M] /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.o > cc1: error: unrecognized command line option "-mlittle-endian" > cc1: error: unrecognized command line option "-mapcs" > cc1: error: unrecognized command line option "-mno-sched-prolog" > cc1: error: unrecognized command line option "-mabi=aapcs-linux" > cc1: error: unrecognized command line option "-mno-thumb-interwork" > /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.c:1: error: bad value > (armv4t) for -march= switch > /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.c:1: error: bad value > (arm9tdmi) for -mtune= switch > make[3]: *** [/embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.o] Error 1 > make[2]: *** [_module_/embedded/tpm_emulator-0.5/tpmd_dev] Error 2 > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/embedded/tpm_emulator-0.5/tpmd_dev' > make: *** [all-recursive] Error 255 > > kindly help me understand the core issue here and point out some solutions. A quick guess is that you use your host gcc and not your target gcc. You most likely have to set CROSS_COMPILE=... Try with "make V=1" to see the exact gcc command line. If you continue to rn into trouble please post your Makefile. 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: Incompatible CFLAGS for kernel module
On Sat, Jul 05, 2008 at 10:33:28AM +0500, Shaz wrote: > On Sat, Jul 5, 2008 at 1:32 AM, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > On Fri, Jul 04, 2008 at 10:34:56PM +0500, Shaz wrote: > >> Hi, > >> > >> I am porting tpm emulator to versatilepb, which is an arm platform. I > >> have some problem with CFLAGS from /arch/arm/Makefile when building > >> the kernel module for this software. I cannot figure out what to do in > >> this case. Following is the error: > >> > >> [EMAIL PROTECTED] tpm_emulator-0.5]# make > >> Making all in tpmd > >> make[1]: Entering directory `/embedded/tpm_emulator-0.5/tpmd' > >> make[1]: Nothing to be done for `all'. > >> make[1]: Leaving directory `/embedded/tpm_emulator-0.5/tpmd' > >> Making all in tpmd_dev > >> make[1]: Entering directory `/embedded/tpm_emulator-0.5/tpmd_dev' > >> CC [M] /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.o > >> cc1: error: unrecognized command line option "-mlittle-endian" > >> cc1: error: unrecognized command line option "-mapcs" > >> cc1: error: unrecognized command line option "-mno-sched-prolog" > >> cc1: error: unrecognized command line option "-mabi=aapcs-linux" > >> cc1: error: unrecognized command line option "-mno-thumb-interwork" > >> /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.c:1: error: bad value > >> (armv4t) for -march= switch > >> /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.c:1: error: bad value > >> (arm9tdmi) for -mtune= switch > >> make[3]: *** [/embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.o] Error 1 > >> make[2]: *** [_module_/embedded/tpm_emulator-0.5/tpmd_dev] Error 2 > >> make[1]: *** [all] Error 2 > >> make[1]: Leaving directory `/embedded/tpm_emulator-0.5/tpmd_dev' > >> make: *** [all-recursive] Error 255 > >> > >> kindly help me understand the core issue here and point out some solutions. > > > > A quick guess is that you use your host gcc and not your target gcc. > > You most likely have to set CROSS_COMPILE=... > > > > Try with "make V=1" to see the exact gcc command line. > > > > If you continue to rn into trouble please post your Makefile. > I tried make V=1 but the loads of info was given for the things that > went right but nothing noticeable where the error is. What is interesting is the gcc commandline for a good case and a bad case. If they do not look the same we are on the right track. > I've attached my arch/arm/Makefile. My build, host and target are on > same system. i am emulating the board with Qemu. The process is very > conventional. I've mounted my rootfs with -o loop and kernel and extra > modules go there with INSTALL_MOD_PATH and INSTALL_MOD_DIR. ARCH=arm > and CROSS_COMPILE=arm-linux- But you do some kind of "external module" build judging from the output above. So the Makefile of interest is the one(s) that is special for your module. At lest the one you have in /embedded/tpm_emulator-0.5/tpmd_dev 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: Incompatible CFLAGS for kernel module
> >>> >> this case. Following is the error: > >>> >> > >>> >> [EMAIL PROTECTED] tpm_emulator-0.5]# make > >>> >> Making all in tpmd > >>> >> make[1]: Entering directory `/embedded/tpm_emulator-0.5/tpmd' > >>> >> make[1]: Nothing to be done for `all'. > >>> >> make[1]: Leaving directory `/embedded/tpm_emulator-0.5/tpmd' > >>> >> Making all in tpmd_dev > >>> >> make[1]: Entering directory `/embedded/tpm_emulator-0.5/tpmd_dev' > >>> >> CC [M] /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.o > >>> >> cc1: error: unrecognized command line option "-mlittle-endian" > >>> >> cc1: error: unrecognized command line option "-mapcs" > >>> >> cc1: error: unrecognized command line option "-mno-sched-prolog" > >>> >> cc1: error: unrecognized command line option "-mabi=aapcs-linux" > >>> >> cc1: error: unrecognized command line option "-mno-thumb-interwork" This all looks like you are using the wrong gcc. And the "make V=1" option should tell you that. > I've noticed some issues in my rootfs and on to it but plz do look at > the Makefile. i might be missing something there instead. The Makefile looks ok. 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 02/10] AXFS: Kconfig and Makefiles
On Thu, Aug 21, 2008 at 01:24:22PM +0200, Arnd Bergmann wrote: > On Thursday 21 August 2008, Jared Hulbert wrote: > > The Kconfig edits and Makefiles required for AXFS. > > > > Signed-off-by: Jared Hulbert <[EMAIL PROTECTED]> > > If you split out this patch separate from the files, please make it the > *last* patch so that you cannot get build errors during a later git-bisect > through the middle of your series. And please use axfs-y := foo.o bar.o as the old axfs-objs := foo.o bar.o ... syntax is deprecated. [Replying to this mail as I lost the original] 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: [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: 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: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
Hi Rob.
On Fri, Jan 02, 2009 at 02:13:30AM -0600, Rob Landley wrote:
> From: Rob Landley
>
> Replace kernel/timeconst.pl with kernel/timeconst.sh. The new shell script
> is much simpler, about 1/4 the size, and runs on Red Hat 9 from 2003.
This part of the changelog is OK except that is fails to
address why we want to get away from perl.
Please drop the remining part of the changelog (but not the s-o-b).
> Peter Anvin added this perl to 2.6.25. Before that, the kernel had never
> required perl to build.
>
> Signed-off-by: Rob Landley
> ---
>
> kernel/Makefile |4
> kernel/timeconst.pl | 378 --
> kernel/timeconst.sh | 91 ++
> 3 files changed, 93 insertions(+), 380 deletions(-)
>
> diff -r d0c7611dcfd6 kernel/Makefile
> --- a/kernel/Makefile Tue Dec 30 17:48:25 2008 -0800
> +++ b/kernel/Makefile Fri Jan 02 00:10:44 2009 -0600
> @@ -115,7 +115,7 @@
> $(obj)/time.o: $(obj)/timeconst.h
>
> quiet_cmd_timeconst = TIMEC $@
> - cmd_timeconst = $(PERL) $< $(CONFIG_HZ) > $@
> + cmd_timeconst = $(CONFIG_SHELL) $< $(CONFIG_HZ) > $@
> targets += timeconst.h
> -$(obj)/timeconst.h: $(src)/timeconst.pl FORCE
> +$(obj)/timeconst.h: $(src)/timeconst.sh FORCE
> $(call if_changed,timeconst)
OK
> --- /dev/null 1969-12-31 00:00:00.0 -0600
> +++ hg/kernel/timeconst.sh2009-01-01 23:53:17.0 -0600
> @@ -0,0 +1,91 @@
> +#!/bin/bash
> +
> +if [ $# -ne 1 ]
> +then
> + echo "Usage: timeconst.sh HZ"
> + exit 1
> +fi
That usage is useless. Either extend it or spend a few lines
in the shell script explainign what the shell script is supposed to do.
> +
> +HZ=$1
> +
> +# Sanity test: even the shell in Red Hat 9 (circa 2003) supported 64 bit
> math.
> +
> +[ $((1<<32)) -lt 0 ] && exit 1
> +
If it fails then add an error message explaining why. So if we get reports that
this
fails then we at least can see something like:
"timeconst noticed that the shell did not support 64 bit math - stop"
> +# Output start of header file
> +
> +cat << EOF
> +/* Automatically generated by kernel/timeconst.sh */
> +/* Conversion constants for HZ == $HZ */
> +
> +#ifndef KERNEL_TIMECONST_H
> +#define KERNEL_TIMECONST_H
Please use __KERNEL_TIMECONST_H. The two underscores are standard.
> +
> +#include
> +#include
> +
> +#if HZ != $HZ
> +#error "kernel/timeconst.h has the wrong HZ value!"
> +#endif
> +
> +EOF
> +
> +# For both Miliseconds and Microseconds
> +
> +for i in "MSEC 1000" "USEC 100"
> +do
> + NAME=$(echo $i | awk '{print $1}')
> + PERIOD=$(echo $i | awk '{print $2}')
> +
> + # Find greatest common denominator (using Euclid's algorithm)
> +
> + A=$HZ
> + B=$PERIOD
> +
> + while [ $B -ne 0 ]
> + do
> + C=$(($A%$B))
> + A=$B
> + B=$C
> + done
> +
> + GCD=$A
> +
> + # Do this for each direction (HZ_TO_PERIOD and PERIOD_TO_HZ)
> +
> + for DIRECTION in 0 1
> + do
> + if [ $DIRECTION -eq 0 ]
> + then
> + CONVERT="HZ_TO_${NAME}"
> + FROM=$HZ
> + TO=$PERIOD
> + else
> + CONVERT="${NAME}_TO_HZ"
> + FROM=$PERIOD
> + TO=$HZ
> + fi
> +
> + # How many shift bits give 32 bits of significant data?
> +
> + SHIFT=0
> + while [ $(( (($TO<<$SHIFT)+$FROM-1)/$FROM )) -lt $((1<<31)) ]
> + do
> + SHIFT=$(( $SHIFT+1 ))
> + done
> +
> + MUL32=$(( (($TO<<$SHIFT)+$FROM-1)/$FROM ))
> + MUL32=$(printf %x $MUL32)
> + echo "#define ${CONVERT}_MUL32 U64_C(0x$MUL32)"
> + ADJ32=$(($FROM/$GCD))
> + ADJ32=$(( (($ADJ32-1)<<$SHIFT)/$ADJ32 ))
> + ADJ32=$(printf %x $ADJ32)
> + echo "#define ${CONVERT}_ADJ32 U64_C(0x$ADJ32)"
> + echo "#define ${CONVERT}_SHR32 $SHIFT"
> + echo "#define ${CONVERT}_NUMU64_C($(($TO/$GCD)))"
> + echo "#define ${CONVERT}_DENU64_C($(($FROM/$GCD)))"
> + done
> +done
Is it a shell limitation that all spaces around operators are missing?
Makes it hard to read..
You should use trap in your shell script so we do not end up with a
partially generated file.
Or you should change the rule in the Makefile to use
a temperary file and then rename it.
We have similar bugs in other places - but no need to add
in more places.
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 2/3]: Remove perl from make headers_install
On Fri, Jan 02, 2009 at 02:14:32AM -0600, Rob Landley wrote: > From: Rob Landley > > Remove perl from make headers_install by replacing a perl script (doing > a simple regex search and replace) with a smaller and faster shell script > implementation. The new shell script is a single for loop calling sed and > piping its output through unifdef to produce the target file. OK > > Sam Ravnborg added this perl to 2.6.27. Drop this part - this is just to make you happy and for no use for others. > > Signed-off-by: Rob Landley > --- > > scripts/Makefile.headersinst |6 ++-- > scripts/headers_install.pl | 46 - > scripts/headers_install.sh | 23 > 3 files changed, 26 insertions(+), 49 deletions(-) > > --- /dev/null 2008-11-21 04:46:41.0 -0600 > +++ b/scripts/headers_install.sh 2008-12-15 22:09:45.0 -0600 > @@ -0,0 +1,23 @@ > +#!/bin/bash > + > +# Grab arguments > + > +INDIR="$1" > +shift > +OUTDIR="$1" > +shift > +ARCH="$1" > +shift Please add a short explanation what this file is used for and what it does. You can take more or less a direct copy from headers_install.pl > + > +# Iterate through files listed on command line > + > +for i in "$@" > +do > + sed -r \ > + -e 's/([ \t(])(__user|__force|__iomem)[ \t]/\1/g' \ > + -e 's/__attribute_const__([ \t]|$)/\1/g' \ > + -e 's...@^#include @@' "$INDIR/$i" | > + scripts/unifdef -U__KERNEL__ - > "$OUTDIR/$i" > +done > + > +exit 0 > diff -r d9b501c91442 scripts/Makefile.headersinst > --- a/scripts/Makefile.headersinstSun Dec 14 16:25:19 2008 -0800 > +++ b/scripts/Makefile.headersinstMon Dec 15 23:30:15 2008 -0600 > @@ -44,8 +44,8 @@ > quiet_cmd_install = INSTALL $(printdir) ($(words $(all-files))\ > file$(if $(word 2, $(all-files)),s)) >cmd_install = \ > -$(PERL) $< $(srctree)/$(obj) $(install) $(SRCARCH) $(header-y); \ > -$(PERL) $< $(objtree)/$(obj) $(install) $(SRCARCH) $(objhdr-y); \ > + $(CONFIG_SHELL) $< $(srctree)/$(obj) $(install) $(SRCARCH) > $(header-y); \ > + $(CONFIG_SHELL) $< $(objtree)/$(obj) $(install) $(SRCARCH) > $(objhdr-y); \ Stick to the coding style i the file and do not add your own. Makefile.headersinst uses tabs for commands and not for indent. 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 3/3]: Convert mkcapflags.pl to mkcapflags.sh
On Fri, Jan 02, 2009 at 02:15:36AM -0600, Rob Landley wrote: > From: Rob Landley > > Convert kernel/cpu/mkcapflags.pl to kernel/cpu/mkcapflags.sh. > > This script generates kernel/cpu/capflags.c from include/asm/cpufeature.h. OK > Peter Anvin added this perl to 2.6.28. Drop it. Implementation looks OK. 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 Fri, Jan 02, 2009 at 05:15:32AM -0600, Rob Landley wrote: > On Friday 02 January 2009 04:16:53 Alejandro Mery wrote: > > Christoph Hellwig escribió: > > > On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote: > > >> On Friday 02 of January 2009, Rob Landley wrote: > > >>> Before 2.6.25 (specifically git > > >>> bdc807871d58285737d50dc6163d0feb72cb0dc2 ) building a Linux kernel > > >>> never required perl to be installed on the build system. (Various > > >>> development and debugging scripts were written in perl and python and > > >>> such, but they weren't involved in actually building a kernel.) > > >>> Building a kernel before 2.6.25 could be done with a minimal system > > >>> built from gcc, binutils, bash, make, busybox, uClibc, and the Linux > > >>> kernel, and nothing else. > > >> > > >> And now bash is going to be required... while some distros don't > > >> need/have bash. /bin/sh should be enough. > > > > > > *nod* bash is in many ways a worse requirement than perl. strict posix > > > /bin/sh + awk + sed would be nicest, but if that's too much work perl > > > seems reasonable. > > > > well, bash is not worse as bash is trivial to cross-compile to run on a > > constrained sandbox and perl is a nightmare, but I agree bash should be > > avoided too. > > > > I think the $(( ... )) bash-ism can be replaced with a simple .c helper > > toy. > > No, $[ ] is the bashism, $(( )) is susv3: > http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04 > > I intentionally switched from $[ ] to $(( )) to make dash work. The focus on this patch is to create a minimal set of dependencies so please document what dependencies / compatibility this patch introduces. It is not obvious for me for example if the script requires sh, bash or dash or whatever. The shebang is so often wrong that this is not docuemnting such things. 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: PATCH [0/3]: Simplify the kernel build by removing perl.
> > I'll fix this and resubmit, it just wasn't ready last night. (If the merge > window is closing soon I could resubmit the other two with Sam's suggestions > and resubmit this one next time 'round, but it was only a couple days to > write > in the first place, once I finally figured out what the perl version was > trying to _do_...) For kbuild only fixes and trivial stuff will be merged until next merge window. Neither of the three patches fall into that category. 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. 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. The program is a prime candidate for a small C program and I hope someone can take the challenge to write it. Migrating from perl to shell does not help us here and the shell version was less readable than the perl version. 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.
> 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 Sun, Jan 11, 2009 at 11:50:31PM -0600, Mark A. Miller wrote: > On Sun, Jan 11, 2009 at 11:35 PM, Sam Ravnborg 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 08/14] Pramfs: Makefile and Kconfig
> + > +config PRAMFS_NOWP > + bool "Disable PRAMFS write protection" > + depends on PRAMFS > + default n > + help > +Say Y here to disable the write protect feature of PRAMFS. n is default so "default n" is not needed. If you reverse the logic (and add a default y) then.. > +ifneq ($(CONFIG_PRAMFS_NOWP),y) > +pramfs-objs += wprotect.o > +endif This is a trivial: pramfs-$(PRAMFS_WRITE_PROTECT) += wprotect.o (I renamed the option to something more descriptive - please do so in the abvoe). > +++ linux-2.6.30/fs/pramfs/Makefile 2009-04-19 11:58:51.0 +0200 > @@ -0,0 +1,13 @@ > +# > +# Makefile for the linux pram-filesystem routines. > +# > + > +obj-$(CONFIG_PRAMFS) += pramfs.o > +obj-$(CONFIG_TEST_MODULE) += pramfs_test.o > + > +pramfs-objs := balloc.o dir.o file.o inode.o namei.o super.o symlink.o Use: pramfs-y := balloc.o ... This match usa later in this file. > + > +ifneq ($(CONFIG_PRAMFS_NOWP),y) > +pramfs-objs += wprotect.o > +endif > +pramfs-$(CONFIG_PRAMFS_XIP) += xip.o 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
>
> Include files.
>
> Signed-off-by: Marco Stornelli
> ---
>
> 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
> + * 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
> +
> +#ifdef __KERNEL__
> +#include
> +#include
> +#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 14/14] Pramfs: XIP operations
On Sat, Jun 13, 2009 at 03:23:13PM +0200, Marco wrote:
> From: Marco Stornelli
>
> XIP operations.
>
> Signed-off-by: Marco Stornelli
> ---
>
> diff -uprN linux-2.6.30-orig/fs/pramfs/xip.c linux-2.6.30/fs/pramfs/xip.c
> --- linux-2.6.30-orig/fs/pramfs/xip.c 1970-01-01 01:00:00.0 +0100
> +++ linux-2.6.30/fs/pramfs/xip.c 2009-06-13 12:54:26.0 +0200
> @@ -0,0 +1,90 @@
> +/*
> + * FILE NAME fs/pramfs/xip.c
> + *
> + * BRIEF DESCRIPTION
> + *
> + * XIP operations.
> + *
> + * Copyright 2009 Marco Stornelli
> + * 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include "pram_fs.h"
> +#include "xip.h"
> +
> +static int pram_find_and_alloc_blocks(struct inode *inode, sector_t iblock,
> + sector_t *data_block, int create)
> +{
> + int err = -EIO;
> + off_t block;
> +
> + lock_kernel();
Can we find other solutions than taking the BKL?
We are trying to get rid of it.
> +
> + block = pram_find_data_block(inode, iblock);
> +
> + if (!block) {
> + if (!create) {
> + err = -ENODATA;
> + goto err;
> + }
> +
> + err = pram_alloc_blocks(inode, iblock, 1);
> + if (err)
> + goto err;
> +
> + block = pram_find_data_block(inode, iblock);
> + if (!block) {
> + err = -ENODATA;
> + goto err;
> + }
> + }
> +
> + *data_block = block;
> + err = 0;
> +
> + err:
> + unlock_kernel();
> + return err;
> +}
> +
--
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: New MMC maintainer needed
On Tue, Jul 28, 2009 at 03:41:37PM -0700, Andrew Morton wrote: > On Tue, 28 Jul 2009 22:14:40 +0100 > Ian Molton wrote: > > > Pierre Ossman wrote: > > > > > MMC discussions tend to often be very system specific, which makes > > > lists such as the arm kernel list more appropriate. Also, I've always > > > tried to steer people to LKML as it allows others to keep a casual eye > > > on things. > > > > I think an MMC list wouldnt be a bad idea now that we have a sort of > > 'distributed maintainership' thing going on... itd help get people up to > > speed... > > I expect that Dave Miller can set up linux-...@vger.kernel.org in a > jiffy. A MAINTAINERS patch should be made if this is done. > > What I am unsure about is whether and how web-based archives of the vger > lists come into being - is it automatic, or should people be asked? It was a manual process when I had linux-kbuild created. I contacted marc and one other place I do not recall right now. 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 > > Acked-by: H. Peter Anvin > > 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 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 > > > > > > Acked-by: H. Peter Anvin > > > > > > 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 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 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 4/6] Add support for LZO-compressed kernels for ARM
On Tue, Aug 11, 2009 at 11:44:18AM +0200, Albin Tonnerre wrote: > Hi Sam, > > On Fri, Aug 07, 2009 at 11:08:16PM +0200, Sam Ravnborg wrote : > > We could add libgcc as a prerequisite. > > Untested patch below. > > When compiling with this patch applied, I get the following error: > > Kernel: arch/arm/boot/Image is ready > LD arch/arm/boot/compressed/vmlinux > /home/albin/x-tools/arm-unknown-linux-uclibcgnueabi/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.3.2/libgcc.a(_dvmd_lnx.o): > In function `__div0': > /home/albin/devel/free-electrons/toolchain/targets/src/gcc-4.3.2/libgcc/../gcc/config/arm/lib1funcs.asm:1079: > undefined reference to `raise' > make[2]: *** [arch/arm/boot/compressed/vmlinux] Error 1 > make[1]: *** [arch/arm/boot/compressed/vmlinux] Error 2 > > I've got no idea where this symbol is defined, though. Has anyone an idea on > this ? To make sure thet hack did what it was intended could you try to build with V=1 and post output of the ld command. 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
