[kbuild-devel] kbuild 2.5 on alpha - take 2
Hi all... updated version of kbuild for alpha . the patch is against kbuild-2.5-2.4.16-2 new this week: - reworked arch/alpha/Makefile.defs.config , this is hopefully both right and more readable - added initrd script support - reworked arch/alpha/lib/Makefile.in, since lib.a order don't matter, cleaned up - misc cleanups/ tyops . - added help entries (if someone could rework on these, that would be nice, my english is .. eeh not that good) questions: -about the stack* in arch/alpha/lib/ , as they are for debug only and obviously for use by people that know what they do, is that ok to let those in the Makeile commented ? - what do you think of the initrd ? should we offer creation of initrd when one has a modularized kernel ? -do I add bootimage / bootpfile to the install or do I keep 'em as installable only - now what ? thanks, ghoz kbuild-2.5-2.4.16-alpha-1.patch.gz Description: GNU Zip compressed data
[kbuild-devel] call for eyes - kbuild 2.5 on alpha
Hi all ... I'm almost done with the alpha port of kbuild-2.5 . The almost part is documenting the installable tagets if they make it in + an issue whith building using 2 trees (see below). The standard (vmlinu[xz]) booting methods build and boot, the other 2 build, but are not tested . I'll cry for testers on the alpha related lists once the kbuild team has reviewd the code . some questions now in no particular order : - the most used kernel format in the alpha world is the vmlinux.gz rather than vmlinuz. is vmlinuz an standard for kbuild2.5, or should i keep the old vmlinuz.gz ? - I'm not quite happy with the bootp installable (you can specify an initrd that most likely should contain modules you just built , so does it make sense to put this target in the list ?) comments ? - Is there a way *not to* change the main Makefile.in when adding targets other than vmlinux/z ( and shouldn't we remove any reference to bzimage/zimage from the main Makefile.in as it is an ix86 only kernel format) ? - I have to build a tool with the local cc :arch/alpha/boot/tools/objstrip that includes asm/elf.h. for the build in the same tree as the source, adding linux/include works ok, but the problem is for building in a separate tree . basicaly, the asm - asm-alpha is not created in the source tree (and apparently not in the objects tree) , and even if it was created, the includes list lacks the objtree/include in the include path . How do i force the creation of the asm link, and should i add in the include list objtree/include ? ( and this is a pain as the system *has* an /usr/include/asm/elf.h wich is outdated , so it builds ok, but then yell that vmlinux is for an unsupported e_machine ... ) now for the more general kbuild-2.5 questions : - with kbuild-2.5, if i make menuconfig , change config options. do i have to make clean before make installable ? if not, I had some troubles (related to network and frame buffer) at link stage . for example : fbmem.c adds calls to initfunctions of fb drivers compiled in. These calls are conditionned by CONFIG_ options . When removing one of the drivers from the config, fbmem.o didn't get rebuilt, and screwed the linking . Is that a core kbuild-2.5 problem ,a Makefile.in issue , or my fault of not having cleaned before rebuilding ? I did't investigate any further, and make cleaned ... Thank you for the review/answers ghoz kbuild-2.5-2.4.16-alpha-0.patch.gz Description: GNU Zip compressed data
[kbuild-devel] kbuild-2.5 and the apha
Hi all, good news, I'm able to compile and boot a kernel built with kbuild-2.5 on my alpha ... I spet the week end fighting non booting kernel only to find out that the problem doesn;t come from the kernel , but from some weird interelation between aboot and my hard drive ( i don't know for sure what the problem is actualy) . i'm now in the process of adding other build targets (rawboot, bootp and so), now the thing is that i'd like to add those new tagets to the configuration tools and config help . With the config.install-2.5 everything should be ok, but i'm not sure the non-alpha guys will be happy to see in the help 3-4 build targets with no meaning for them ... Is there a way we could split the help entries into arch specific entries ? like using config variables CONFIG_INSTALL_$ARCH_VMLINUX or something ? That way each arch would only see it's build targets .. is it doable ? thanks ghoz ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] kbuild-2.5 and the apha
On Tuesday 11 December 2001 19:26, Ghozlane Toumi wrote: On Tuesday 11 December 2001 18:54, you wrote: There's already lots of help entries for non-global options. mmmh... actually affter a quick check, i now understand we were not talking about the same things ... I was talking about the new CONFIG_INSTALL_* configuration options introduced by kbuild-2.5, and more specificaly of the options used to choose the build targets . as CML1 uses the first entry to get the help, we have to put in the help all the targets on all the arches, ouch ... hopefully this help limitation will go away with CML2. ghoz ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] alpha/lib/*.S includes userspace headers ...
'lo all... still converting the alpha to kbuild-2.5.. I thought that we tried to avoid at all costs including userspace headers, it seems that some assembler source in arch/alpha/lib/ have a #include alpha/regdef.h , and on my system it points to /usr/include/alpha/regdef.h , wich is a self contained header owned by glibc. From what I understood, the regdef.h contains definitions/uses of registers according to gcc's calling convention, so i guess it may change depending on gcc version ... What do i do now ? do i trick kbuild to add /usr/include in the includes, or do I rip the .h and copy it to the asm-alpha directory ? speaking of includes, why does kbuild adds to the include path -I/usr/lib/gcc-lib/alpha-redhat-linux/egcs-2.91.66/include ? thank you .. ghoz ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Converting the 2.5 kernel to kbuild 2.5
On Monday 03 December 2001 20:13, Keith Owens wrote: I just had a quick look at arch/alpha makefiles. kernel/Makefile - no obvious conversion problems. asm_offsets moves to arch/alpha and is renamed to asm-offsets using the standard code. Could you take a look a the attached makefile.in , it's in alpha/kernel, for 2.4.16 , i'd welcome any comment, specificaly regarding the ifneq ($(CONFIG_ALPHA_EB64P)$(CONFIG_ALPHA_EB66),) obj-y+= sys_eb64p.o endif translations and the like ... btw, is there a way to test rules correctness without booting and finding the hard way if the link succeeded or not ? does comparing nm output of vmlinuxes built with the old and new kbuild sounds right, or am i smoking bad stuff ? thank you ghoz --- expsyms(alpha_ksyms.o) select(head.o) select(entry.o traps.o process.o osf_sys.o irq.o irq_alpha.o signal.o setup.o ptrace.o time.o semaphore.o alpha_ksyms.o # # FIXME! # These should be made conditional on the stuff that needs them! # select(irq_i8259.o irq_srm.o es1888.o smc37c669.o smc37c93x.o ns87312.o) select(CONFIG_VGA_HOSE console.o) select(CONFIG_SMP smp.o irq_smp.o) select(CONFIG_PCI pci.o pci_iommu.o) select(CONFIG_SRM_ENV srm_env.o) ifsel (CONFIG_ALPHA_GENERIC) select( core_apecs.o core_cia.o core_irongate.o core_lca.o core_mcpcia.o core_polaris.o core_t2.o core_tsunami.o core_titan.o sys_alcor.o sys_cabriolet.o sys_dp264.o sys_eb64p.o sys_eiger.o sys_jensen.o sys_miata.o sys_mikasa.o sys_nautilus.o sys_titan.o sys_noritake.o sys_rawhide.o sys_ruffian.o sys_rx164.o sys_sable.o sys_sio.o sys_sx164.o sys_takara.o sys_rx164.o sys_wildfire.o core_wildfire.o irq_pyxis.o) else # Core logic support select(CONFIG_ALPHA_APECS core_apecs.o) select(CONFIG_ALPHA_CIA core_cia.o) select(CONFIG_ALPHA_IRONGATEcore_irongate.o) select(CONFIG_ALPHA_LCA core_lca.o) select(CONFIG_ALPHA_MCPCIA core_mcpcia.o) select(CONFIG_ALPHA_T2 core_t2.o) select(CONFIG_ALPHA_TSUNAMI core_tsunami.o) select(CONFIG_ALPHA_TITAN core_titan.o) select(CONFIG_ALPHA_POLARIS core_polaris.o) select(CONFIG_ALPHA_WILDFIREcore_wildfire.o) # Board support select(CONFIG_ALPHA_ALCOR sys_alcor.o) select(CONFIG_ALPHA_XLT sys_alcor.o) select(CONFIG_ALPHA_CABRIOLET sys_cabriolet.o) select(CONFIG_ALPHA_EB164 sys_cabriolet.o) select(CONFIG_ALPHA_EB66P sys_cabriolet.o) select(CONFIG_ALPHA_LX164 sys_cabriolet.o) select(CONFIG_ALPHA_PC164 sys_cabriolet.o) select(CONFIG_ALPHA_DP264 sys_dp264.o) select(CONFIG_ALPHA_SHARK sys_dp264.o) select(CONFIG_ALPHA_TITAN sys_titan.o) select(CONFIG_ALPHA_EB64P sys_eb64p.o) select(CONFIG_ALPHA_EB66sys_eb64p.o) select(CONFIG_ALPHA_EIGER sys_eiger.o) select(CONFIG_ALPHA_JENSEN sys_jensen.o pci-noop.o) select(CONFIG_ALPHA_MIATA sys_miata.o) select(CONFIG_ALPHA_MIKASA sys_mikasa.o) select(CONFIG_ALPHA_NAUTILUSsys_nautilus.o) select(CONFIG_ALPHA_NORITAKEsys_noritake.o) select(CONFIG_ALPHA_RAWHIDE sys_rawhide.o) select(CONFIG_ALPHA_RUFFIAN sys_ruffian.o) select(CONFIG_ALPHA_RX164 sys_rx164.o) select(CONFIG_ALPHA_SABLE sys_sable.o) select(CONFIG_ALPHA_BOOK1 sys_sio.o) select(CONFIG_ALPHA_AVANTI sys_sio.o) select(CONFIG_ALPHA_NONAME sys_sio.o) select(CONFIG_ALPHA_P2K sys_sio.o) select(CONFIG_ALPHA_XL sys_sio.o) select(CONFIG_ALPHA_SX164 sys_sx164.o) select(CONFIG_ALPHA_TAKARA sys_takara.o) select(CONFIG_ALPHA_WILDFIREsys_wildfire.o) select(CONFIG_ALPHA_MIATA irq_pyxis.o) select(CONFIG_ALPHA_RUFFIAN irq_pyxis.o) select(CONFIG_ALPHA_SX164 irq_pyxis.o) endif # GENERIC ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Converting the 2.5 kernel to kbuild 2.5
Hi all 2.5.2-pre2 Remove kbuild 2.4 code, rename Makefile-2.5 to Makefile. i386, ia64, sparc, sparc64 can compile using kbuild 2.5. Other architectures cannot compile until they convert to kbuild 2.5. The kbuild group can help with the conversion but without access to a machine we cannot test other architectures. Until the other archs have been converted, they can stay on 2.5.2-pre1. How hard is the translation from 2.4 to 2.5 ? I happen to be using an alpha as my main computer, but i'm quite new to this arch, so if the conversion doesn't require heavy guruness i guess i can help.. if not, i can at least test ... ghoz ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Random configurator
On Sun, 29 Apr 2001, Keith Owens wrote: I dimly remember that somebody had a script to generate random configurations for kbuild. Is there a reasonably current version available, for any 2.4 kernel? I want to stress test my 2.5 rules. hi, sory for the delay , I made something like that some time ago, the patches apply with offsets , but it's otherwise ok . i'ts based on make oldconfig , but rather than asking you the questions, it answers by itself automagically . so it adds the following options : make randconfig answers randomly to the questions (see bellow) . make allyes answers 'yes' to all questions . make allno answers 'no' to all questions . make allmod answer 'm' if avaiable, 'yes' else . you can specify defaults in .force_default file, it uses the same syntax as the .config file, with some additions : 8 #.force_default sample # # force CONFIG_MODULES to yes CONFIG_MODULES=y # we don't want SGI workstation support as it diables a lot of options # you can specify CONFIG_VISWS=n , or in .config's fashion : # CONFIG_VISWS is not set # you can specify a list of values for int and hex config options # the # is required : # list CONFIG_NAME val1,val2,val3 # for int options, you can use ranges in the form : # the # is required : # range CONFIG_OPTION min max 8 A direct specification of the values in .force_default has priority over a list, and a list has higher priority over a range. Answers randomised are bool(), tristate(), dep_tristate() and choice(). list can be used for int() and hex() range only for int() unless specified in the .force_config int, hex, and strings use the default values reminder : this is a dirty hack over make oldconfig . it's slow, ugly, but worked for me when i needed it (c) , so YMMV . ghoz Makefile-2.4.0-test9.20001010.patch.gz Configure-2.4.0-test9.20001010.patch.gz
