Re: [lkcd-devel] Re: [kbuild-devel] sorting out the kerntypes mess
On Sun, Jan 30, 2005 at 11:16:35PM +0100, Arnd Bergmann wrote: On S?nndag 30 Januar 2005 18:37, Christoph Hellwig wrote: So you expect kerntypes-y := file.o to be present in one or a few places outside arch/ And then in one or a few files within arch/ the arch specific types are brought in with kerntypes-y := archfile.o And kbuild shall link the resuting files to a single kerntypes.o file to be located in the root of the kernel output dir. Currenly it's called Kerntypes, which would make sense to be kept, but else yes. How about simply linking the kerntypes files into vmlinux? AFAIK, lcrash is able to use vmlinux with stabs information instead of a separate kerntypes file. Supporting this could be as simple as putting obj-y += $(kerntypes-y) $(kerntypes-y): CFLAGS += $(KERNTYPES_FLAGS) into scripts/Makefile.build, although I haven't tried that. Linking it into vmlinux would increase vmlinux size, which is exactly what the Kerntypes approach is trying to avoid. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] sorting out the kerntypes mess
On Sun, Jan 30, 2005 at 06:34:48PM +0100, Sam Ravnborg wrote: First trying to understand exactly what you want. So you expect kerntypes-y := file.o to be present in one or a few places outside arch/ And then in one or a few files within arch/ the arch specific types are brought in with kerntypes-y := archfile.o And kbuild shall link the resuting files to a single kerntypes.o file to be located in the root of the kernel output dir. Currenly it's called Kerntypes, which would make sense to be kept, but else yes. There are a few (solveable) issue with this. - kbuild needs to keep track of all kerntypes.y files. This is done for the kernel with a built-in.o file that links all .o files for a given dir and subdirs. In this was the final link is just a few built-in.o files (+ a bitmore). - Addind kerntypes-y would make kbuild infrastructure even more scary than today. There most be some very good reasons to add more complexity to the current implmentation. Maybe a simpler solution could be deployed: One file for all of the kernel located in kernel/kerntypes.o Then the arch makefile can link in their relevant files in a post processing step like when we build bzImage and the like. This requires much less support in common kbuild files. That could work aswell. Note that e.g. for s390 most of the additional bites are for drivers/s390/ datastructures which would make sense to be done with a drivers/s390/kerntypes.c file, but if it's really that bad let's go for your scheme. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [PATCH 2.4.25] enable cross-compilation from Mac OS X
On Tue, Feb 24, 2004 at 02:23:23PM +, Martin Schaffner wrote: -ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/) +ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/ -e s/Power\ Macintosh/ppc/) You can override this manually, and doing so is the right thing to do. (Btw, what crack did the Apple folks smoke when putting Power Macintosh in their uname output?..) --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Needed help for UML kbuild.
On Wed, Dec 24, 2003 at 08:19:23PM +0100, BlaisorBlade wrote: Makefile.build change is just cosmetic(changing the shown tag; I must change it more to fix the filename alignment; but why don't you use a tab for this?). The Makefile.lib, instead, is the core change: objects listed in UML_USER_OBJS get completely different CFLAGS. Please don't use shouting names.. The list always contains, in the arch/um subfolders, all objects whose name matches %_user.o(as it has always been for UML). This doesn't sound like a good heuristic, imagine a driver using e.g. foo_user.c for the chardev user interface. In general I'd suggest adding parallel infrastructure for user-$(CONFIG_FOO) variables in addition to the current obj-* and host-*. The only problem you could get with that is that you need to take special care of the link order. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Problems with make menuconfig of linux2.6.0-test5
On Sat, Sep 13, 2003 at 08:56:36PM +0200, Martin Schaffner wrote: Hi, When doing make menuconfig of linux2.6.0-test5, I noted some issues: 1) The configuration item PowerMac DMA sound support under Sound card support in the Sound Menu should be in the Open Sound System Menu, because the associated file is in the oss subdirectory, and because there is also an ALSA driver for PowerMac sound. dmasound uses the oss API but is a very different implementation.. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel ---end quoted text--- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: 2.5 kbuild: use of '-z muldefs' for LD?
On Mon, Jun 09, 2003 at 01:56:59PM +0200, Jaroslav Kysela wrote: one object file for more targets. Example: -- snd-ice1712-objs := ice1712.o delta.o hoontech.o ews.o ak4xxx.o snd-ice1724-objs := ice1724.o amp.o revo.o aureon.o ak4xxx.o # Toplevel Module Dependency obj-$(CONFIG_SND_ICE1712) += snd-ice1712.o obj-$(CONFIG_SND_ICE1724) += snd-ice1724.o -- The ak4xxx.o module is shared and has defined a few public functions. Unfortunately, the default build-in.o rule fails when targets are requested to be included into the solid kernel because the public functions are duplicated in snd-ice1712.o and snd-ice17124.o. I can instruct the ld compiler to ignore the multiple definitions using '-z muldefs': EXTRA_LDFLAGS = -z muldefs But it seems like a hack for me. Does anybody have another idea to solve my problem? Move ak4xxx.o out of the multi-obj rules. Just declare a new helper- config option CONFIG_SND_AK4XXX that gets defined by all drivers using it and add obj-$(CONFIG_SND_AK4XXX)+= ak4xxx.o You'll just have to make sure to export all symbols in 2.5 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: 2.5 kbuild: use of '-z muldefs' for LD?
*grr* Can you _please_ stop the stupid practice of Cc'ing members-only lists? Thanks. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: 2.5 kbuild: use of '-z muldefs' for LD?
On Mon, Jun 09, 2003 at 04:01:41PM +0200, Jaroslav Kysela wrote: But this solution will create a new kernel module. The shared code is really small and having small codes in separated modules is waste of memory in my eyes. Well, if you want separate copies of it you have to make sure the symbols won't clash, e.g. calling all functions in it MYPREFIX_foo and then do #define MYPREFIXKBUILD_MODNAME or something like that --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: linux kernel conf 0.8
On Wed, Oct 09, 2002 at 06:29:03PM +0200, Roman Zippel wrote:
Hi,
On Wed, 9 Oct 2002, Randy.Dunlap wrote:
So I think that you and Roman are close to agreement, when Roman
has the library backend ready. Of course someone needs to do a
reference implementation with it also, but it doesn't need to
ship with the kernel.
We ship BK documentation, so shipping a small QT app can't be that
problematic. :)
Creating the library isn't that difficult (kbuild is currently my
problem here) and I'll still have to write some API documentation for it
and some glue code to load the library.
Why don't you just separate the library from the kernel at all, making
it a similar package. We depend on a few external, kernel-specific
packages anyway, and depending on libkconfig wouldn't make the situation
worse. Instead people could keep their tools build one time around in
/usr/{local/,}bin (especially important with qt-monsters :)) and if
there is a change in the language Documentation/Changes would get
updated to the new required version and people had to update it,
similar to the gcc situation for a new development kernel.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
On Mon, Aug 19, 2002 at 11:48:00PM +0200, Kai Henningsen wrote: [EMAIL PROTECTED] (Greg Banks) wrote on 19.08.02 in [EMAIL PROTECTED]: In http://marc.theaimsgroup.com/?l=linux-kernelm=101387128818052w=2 David Woodhouse gives an idea of what would be necessary to get a new language+parser accepted. Can you achieve that yet? As for the idea of a new parser, if we could define a parser interface that can be made to work with both menuconfig and xconfig (creating a working oldconfig and config seems rather trivial), then writing a common parser to support that interface, and testing it David's way, should not be too hard. Reading and writing .config, and parsing the various config.in and Configure.help files, shouldn't give any unsurmountable problems. Something like mconfig? Just needs someone to write an X interface (and some more time for me to get 0.21 out of the door..). --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config build system
On Fri, Dec 28, 2001 at 03:39:02PM -0500, Eric S. Raymond wrote: It may be that the reason our experiences have been different is because we focus on different target languages. But I think my experience is an existence proof that there *is* demand for localization and that meeting it can have useful results. Is your native language something different thæn english or Al's? Localization for technical messages sucks. badly. Just take a look at a european computer magazine, you will find lots of english words in the text because there is no german/frensh/whatever one. Trying to use different grammar doesn't help the understanding. Christoph -- Of course it doesn't work. We've performed a software upgrade. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, May 18, 2001 at 12:04:34PM -0400, Eric S. Raymond wrote: Alan Cox [EMAIL PROTECTED]: I don't want to do (a); it conflicts with my design objective of simplifying configuration enough that Aunt Tillie can do it. I won't do that unless I see a strong consensus that it's the only Right Thing. Its a good way of getting the defaults right. It may also be an appropriate way of guiding presentation (eg putting the stuff the ruleset says you wont have under a subcategory so you would see CPU type Devices blah blah Other Options IDE disk Cardbus I want to understand what you're driving at here and I don't get it. What's the referent of Its? Are you saying you think Aunt Tillie's view of the world should guide the presentation of options? Aunt Tillie shouldn't try to manually configure a kernel. Christoph P.S. _please_ shorten your .sig -- Whip me. Beat me. Make me maintain AIX. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, May 18, 2001 at 01:22:35PM -0400, Eric S. Raymond wrote: Michael Meissner [EMAIL PROTECTED]: On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: Aunt Tillie shouldn't try to manually configure a kernel. Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After all, all of us at one point in time were newbies in terms of configuring kernels, etc. And if she doesn't, maybe her teenage daughter Muffy wants to learn. You know, the one with the unicorn appliques and the pink scrunchies and the Back Street Boys posters in her bedroom? That's ok as long as she doesn't add backstreet boys songtexts as long as your signature to her mails. On the other hand she should _really_ learn how to do it - like we all did. Dammit, if we're serious about empowering people with free software we can't limit ourselves with the attitude that configuring kernels (or anything else) is the sacred preserve of a geek elite. I see _no_ reason to give up my control for people with an attitude that configuring kernels will not need knowledge of what one is doing. Your point is basically: Lets rewrite the kernel in VBA to make every word user capable of driver hacking. That doesn't work. Christoph -- Auch der Dumme hat manchmal einen gescheiten Gedanken. Er merkt es nur nicht. -- Danny Kaye ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote: Jes Sorensen wrote: Telling them to install an updated gcc for kernel compilation is a necessary evil, which can easily be done without disturbing the rest of the system. Updating the system's python installation is not a reasonable request. Au contraire. It is very reasonable to have both python and python2 installed. Having two different gcc versions installed is a big pain in the arse. Fump. Some distributions do even come with two gcc's out of the box. With the whole egcs and gcc2.95 (dunno about 3.0) you can even share the compiler driver if you want. Christoph -- Of course it doesn't work. We've performed a software upgrade. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote: Alan, it sounds very much like you just said something stupid. This seems sufficiently unlikely that I am shaking my head in disbelief and fingernailing wax out of both ears (and if you think doing both those things at once is easy try it sometime :-)). Do you really believe that anyone is going to maintain the CML1 tools for as long as a nanosecond after they get dropped out of the kernel tree? I _will_ continue to maintain mconfig (after mec stopped even before cml2). Christoph -- Of course it doesn't work. We've performed a software upgrade. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
