Re: [kbuild-devel] Re: installing header files
Brendan J Simon wrote: Keith Owens wrote: Does anyone know how Linux distros (debian, redhat, etc) populate the linux header files in /usr/include/linux ? Is a crude copy or is it done via a make target ? According FHS (and Debian, RH,... follow FHS), /usr/include/linux is created by glibc. Thus ask glibc people about how they to do that. Anyway it would be nice to have some infrastructure in kbuild-2.5 to generated headers files. I.e. for external modules and other *strict* kernel related programs. giacomo ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Disgusted with kbuild developers
Daniel Phillips wrote: . A Microsoft engineer wrote scripts/Configure. For three years, I have lived in fear that Microsoft would notice this fact and use it to attack Linux through public relations channels or legal means. They haven't yet, so I have been wrong so far. Teehee. I don't think you have anything to worry about, Microsoft would be incredibly embarassed to admit they're contributing to 'problem number 1'. I agree, but we know some strange 'behaviour' of MS. They have a lot of lawers, they can make us a lot of trouble. (You will notice that there are no copyright statment on that file, only the name of authors). Remember the RMS (a flame with the word 'ESR' MUST have also the 'RMS' :-)) way to include 'free' patches: sign and send to FSF a piece of paper, that the patches CAN be included. I think nobody in Linux have done that, thus we can expect some more troubles and microsoft is a large troubles-maker giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2-2.1.3 is available
Daniel Phillips wrote: I detect a slight lack of symmetry here, shouldn't it be make autoconfig? Pardon me if this has been beaten to^W^W discussed above. Yes. It should be make autoconfig, for symmterty reasons :-) I called the files and the project autoconfigure, because 'autoconfig' is already an utility made by GNU. (not related to kernel) giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2-2.1.3 is available
Eric S. Raymond wrote: Kai Henningsen [EMAIL PROTECTED]: I think right now, the only halfway reasonable thing is to do what ttyname() does: get the devide number off stat(/), and search it in /dev. (Besides, you can figure out part of the answer - about as much as the autoprober does now - from the major anyway.) There's a swamp there -- getting from the major device number to the right config symbol seems like a long and tortuous process. First you have to get from major number to driver, then from driver to config symbol. I don'rt thing the metadata for either of these is present in the current driver infrastructure. Major number tell you what kind of device is attached: IDE, SCSI,... (Documentation/devices.txt). From this info, you parse the /proc/ide , /proc/scsi to see what driver is attached to a particular device. giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Hardware Inventory [was: Re: ISA slot detection on PCI systems?]
Greg KH wrote: What about devices that are supported by more than one driver? How do you handle that? (see the USB keyspan_pda and keyspan drivers for an example.) I check the devices supported by multiple drivers, and normally I comment both probes (This is why I have so much probes commented. These drivers are marked in my db '## 2x'). Sometime I arbitrary choice a device. I.e. in FS 'autofs4' is prefered to 'autofs'. In the case of USB, two driver 'register' the uhci cards. I prefer USB_UHCI_ALT to USB_UHCI (arbitrary choice). I would like comments and correction to these choices. (The kernel is to big to know all, and the sources are not usefull in some cases) BTW the database is available to all. If somebody need it I can confirm that the database is complete (for MODULES_TABLE items). The database have these informations: - type (pci, usb, pnp,...) - device ID (ev. with class) or class ID, or interface ID or function ID, or both - configuration variable - source (the kernel file where the device is defined) (for non autoprobe use, you should discard the ev. first '#', CONFIG = _ means 'always', in pci the ! before the source means from MODULES_TABLE, the other pci are detected by other methods (no so accurate) giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] RE: CML2-2.0.0 is available -- major release announcement
Leif Sawyer wrote: Picked USB HCI's as modular (building all) from VIA motherboard. (Don't really need the OHCI built here) This is a know problem. The problem is: we don't know yet if a given USB configuration is a USB card, a USB kernel support (i.e. USBFS, OHCI, EHCI...). The solution is to modify the configuration rules, adding the USB_CARDS (as Eric proposed for ISA_CARDS). But this rules change can be done only after CML2 is included into the kernel. Missed HOTPLUG (based on USB, and configure_help - this may just be cleanup in the help text to remove references to USB if hotplug is not needed/required) Eric: Rule error ? Missed APM support (is enabled in running kernel) I know. I don't know if I should autodetect APM support. On some machine APM crash the kernel and in some more machine you must tune the APM options. I'm not an APM expert, so I need some help. Missed my parallel port. Missed my floppy drive! I have some problem with these rules. I should find a solution on how to detect these on a x86 wihout breaking the other archs. Probably the best solution is to change the rules: the floppy disk is linked to CONFIG_FLOPPY (or an other non conflicting names) and the various archs controller configuration is derives from FLOPPY and ARCH_*. Missed SCSI_Generic Missed Unix Domain Sockets! Missed Packet Socket (based on running kernel) Hard to detect these 'software devices'. Some suggestions? Missed PS/2 mouse hmm. I forgot these rules during the conversions. [but ATARI PS/2 conflict with this] giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-1.9.9
Eric S. Raymond wrote: Giacomo A. Catenazzi [EMAIL PROTECTED]: With attacched config.out, the MODULES is a tristate. I think this is wrong, because modules support can be only build-in. MODULES is special, see the dicumentation on trit_tie. In my config.out I can have 'CONFIG_MODULES=m'. This is very bad! 1) MODULES MUST be a boolean (for the kernel). The kernel sources checks if CONFIG_MODULES is defined. So you are breaking kernel! 2) You should document the special case 'm' into the help (former Configure.help) You should rename (CML2's) MODULES and then derive the (kernel) MODULES fomr the new symbol, but you cannot give the kernel a 'CONFIG_MODULES=m'. This have consequence to break kernel. giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] CML2 1.9.7 is available
Keith Owens wrote: = Why are those deduction messages appearing in menuconfig? I just did make oldconfig, the config should be stable. I did not change anything in menuconfig, just saved it. = OUCH! The output from make menuconfig has significantly more options than make oldconfig when given exactly the same input. I thought one of the selling points for CML2 was different front ends but with identical back end processing. I don't like the way that the resulting config varies when fed to different front ends. There are two policy to what symbols should be written: 1) not visible symbols should not be written in final config.out 2) all symbols should be written. CML1 use policy 1). CML2 actually seem to use also 1), but with few exceptions (previously visible symbols,...), but it is not clear what is the right behaviour. What policy we should adopt? The second proposal (which I don't like), seems to be simpler and cleaner, and with kbuild-2.5 it should be no problem with extra symbols set to 'no'. Could we move to the second proposal? giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
[EMAIL PROTECTED] wrote: In fact, here's all I want to know about the whole CML2/kbuild 2.5 issue. Right now I upgrade my kernel like this (simplified slightly): apply latest patches mv .config .. make mrproper mv ../.config . make oldconfig make dep make bzlilo modules modules_install reboot Will I still be able to do it this simply in 2.5.x? (Assuming there's eventually a 2.5.x I can get to compile cleanly. :-) Yes you can do. hmm. only for the CML2 part. The new kbuild-2.5 (also the new Makefile) will no more work with your command: make dep: is no more needed make bzlilo modules modules_install: it would be a simble make install: (and you configure with CML1/CML2 what install means). giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] get_versions.sh
Hello Eric, Now I remember that you propose to me to detect the version of tools and program, to give user some warning about dangerous configurations in CML2. In people.debian.org/~cate/files/kautoconfigure/autoconfigure/new/ you will find the latest version. It detects and feed version and tools type (GNU or other) into a config.out file. To use: bash get_versions.sh For bug report, use the: bash get_versions.sh --debug IIRC I've already annonced a the release of that file some time ago. Anyway, if you still intend to support it into CML2, tell me so that I will update it. giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Forgotten driver
Keith Owens wrote: I have no idea what you mean by that. Which filenames are missing the leading 's' and which file is missing it? in drivers/pcmcia/Makefile.in: objlink(sa1100_cs.o sa1100_generic.o) objlink(CONFIG_SA1100_ASSABET sa1100_cs.o a1100_assabet.o) objlink(CONFIG_ASSABET_NEPONSET sa1100_cs.o a1100_neponset.o) objlink(CONFIG_SA1100_H3600 sa1100_cs.o a1100_h3600.o) objlink(CONFIG_SA1100_CERF sa1100_cs.o a1100_cerf.o) objlink(CONFIG_SA1100_GRAPHICSCLIENTsa1100_cs.o a1100_graphicsclient.o) objlink(CONFIG_SA1100_XP860 sa1100_cs.o a1100_xp860.o) objlink(CONFIG_SA1100_PANGOLIN sa1100_cs.o a1100_pangolin.o) objlink(CONFIG_SA1100_YOPY sa1100_cs.o a1100_yopy.o) objlink(CONFIG_SA1100_FREEBIRD sa1100_cs.o a1100_freebird.o) objlink(CONFIG_SA1100_PFS168sa1100_cs.o a1100_pfs168.o) objlink(CONFIG_SA1100_JORNADA720sa1100_cs.o a1100_jornada720.o) objlink(CONFIG_SA1100_FLEXANET sa1100_cs.o a1100_flexanet.o) objlink(CONFIG_SA1100_SIMPADsa1100_cs.o a1100_simpad.o) objlink(CONFIG_SA1100_GRAPHICSMASTERsa1100_cs.o a1100_graphicsmaster.o) objlink(CONFIG_SA1100_ADSBITSY sa1100_cs.o a1100_adsbitsy.o) objlink(CONFIG_SA1100_STORK sa1100_cs.o a1100_stork.o) You should subst. [[:blank:]]a1100 into sa1100 (as in old Makefile) giacomo PS: Sorry for my bad bug report. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: kbuild 1.3 comments and bugs
Keith Owens wrote:
On Wed, 10 Oct 2001 16:39:16 +0200,
Giacomo Catenazzi [EMAIL PROTECTED] wrote:
Keith Owens wrote:
Maybe a better solution: mrproper don't depend on .config.
I convert user_command() to 'make' rules in place, so the result
replaces user_command(). The expanded commands automatically add to
the CLEAN list. Some user_commands() are conditional on CONFIG_xxx so
I need a .config to get the correct expansion of the global Makefile.
The MRPROPER list includes the CLEAN list. Without a .config I have
no
CLEAN list.
what I propose:
mrproper:
if [ -f .config ]; then ${MAKE} true_mrproper
else
rm -f ${explicit list of file that could exists \
before .config (cml2 and kbuild files)}
fi
[this is untested simplified version, and it shouldn't work with
shadow tree, but do shadows tree exists without .config?]
Reading again your sentences I have another question (yet I don't
have access on Linux boxes).
If I do:
make menuconfig installable
make menuconfig
# and I change the configurations
make installable
make mrproper
Would this clean the files generated only on first
'installable' ?
To speed-up more, you can remove default the verbose things in your
make scripts.
(with preprocessor instead of runtime)
If user use a makefile parameter VERBOSE, the makefile vould be build
verbose.
The generated global Makefile has variables like KBUILD_QUIET and
PP_MAKEFILE3_FLAGS. I deliberately left this for make to evaluate
instead of doing them during the generation phase. That lets you
debug
kbuild quickly by specifying the failing target, NO_MAKEFILE_GEN
(bypass pre-processor) plus the debug flags to see what is occurring.
Ok. It was only a proposal. I agree with KBUILD_QUIET, but I think
nobody (else kbuild's people) need PP_MAKEFILE3_FLAGS.
Hmm, anyway the speed up is minimal, thus forget this proposal.
giacomo
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: kbuild 1.3 comments and bugs
Keith Owens wrote:
On Sat, 29 Sep 2001 17:05:57 +0200,
Giacomo A. Catenazzi [EMAIL PROTECTED] wrote:
BUG:
$ make mrproper
$ make mrproper
Error: you must create a .config first
mrproper should not depend on .config (contents and
existance).
kbuild 2.4 relies on everybody coding the mrproper targets at the top
level which is manual and error prone. kbuild 2.5 automatically
generates the mrproper targets from each Makefile.in, the disadvantage
is that it needs a config to do that. However that only applies if
source and object are in the same directory, if you use a separate
object directory then make mrproper simply erases everything in the
object directory. I am willing to accept the need to have a config to
do make mrproper to get an automatic cleanup.
Maybe a better solution: mrproper don't depend on .config.
If .config exists, do the actual make mrproper, else
do nothing. (or maybe cancel the ev. cml[12] generated file.
(This means you rename mrproper to mrproper-r and implement
an other mrproper. This would be an exception: make will call
another make).
COMMENT:
Your documentation is extensive, but I didn't found
the meaning of targets.
Which targets?
target: mrproper, clean, installable, ...
BTW I didn't like installable. Use something more ... liek a linusism,
like make world/linux/domination/free/penguin
BUG ?
making arch/i386/boot/bbotsect.o:
old:
bbootsect.s: Assembler message:
bbootsect.s:257: Warning
new:
/tmp/ccM: Assempler message
/tmp/ccM5???:257 Warning ...
What is the more user-friendly message?
The cause: you forget '-pipe'.
-pipe does not really help. Instead of /tmp/ccM, -pipe results in
messages for {standard input}. kbuild 2.4 displays the .s name because
bbootsect.o is built in two stages, bbootsect.S - bbootsect.s -
bbootsect.o. I will look at doing a two stage conversion in kbuild 2.5
for .S files. The second stage would use $(AS) instead of $(CC).
Sorry for my stupid comment. The main issue was that kbild-2.4 use
-pipe in AS flags, kbuild-2.5 no.
COMMENT
You should change the number of the phases.
I really don't like phase 5 before phase 4.
(Let a missing phase number of first compile,
but let the pahse always be in order)
Phase 5 is feedback from the previous run, its numbering reflects that
it is a continuation of the previous build. However I expect to remove
phase 5 anyway, when I replace the individual .d and .cd files with a
global database. That will significantly speed things up.
More speedup? Should I insert a sleep 1 before every file build to not
burn my laptop? :-)
To speed-up more, you can remove default the verbose things in your make scripts.
(with preprocessor instead of runtime)
If user use a makefile parameter VERBOSE, the makefile vould be build verbose.
giacomo
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Kernel Build for 2.5, Release 1.3 is available.
Hello. I tried kbuild 1.3, it compile without problems. But I noticed that some asm warning come with /tmp/. So I think that -pipe option is not right propagated. (on i386). BTW how to debug kbuild? When I recompile kernel I see phase 5 before phase 4. Should you rename the phases? giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML[12]: no and don't care
Eric S. Raymond wrote: Giacomo Catenazzi cate@dplanet. Now if I 'make oldconfig' with my old CML1 .config and CML2 oldconfig, I should confirm all 'No' options. (and menuconfig show NEW to all 'N' options). I want that your CML2 (probably in makefile) implements something as actual Configure, so that it translates '# CONFIG_FOO is not to CONFIG_FOO=no in the long transition phase. (IMHO people will migrate from CML1 to CML2 nearly the release of 2.5.2 (developers) and 2.6.x (normal/expert people), so this transition phase is very long) Do you mean that you want me to generate .config-is-not? no, but that you use also the #CONFIG_FOO is not setting. I could do that easily enough in configtrans.py. But I don't see any evidence that anyone has ever actually used .config-is-not for anything. If there had been demand for it, the feature would have been ported to the menuconfig and xconfig scripts long ago. configtrans.py traslates also CML1 config to CML2 format, right? Why you don't call configtrans.py (to translate the config) also before the cmlconfigure.py in the makefile ? giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]
Eric S. Raymond wrote: Giacomo A. Catenazzi [EMAIL PROTECTED]: My proposal is instaed of complain about configuration violatation, you just wrote the possible correct configuration and prompt user to select the correct configuration. In the case you cite, e.g. oldconfig shoud prompt: 1) SMP=n 2) RTC=m 3) RTC=y (assuming the ARCH is invariant). You, and the other person who proposed this previously, are getting way too hung up on this particular easy case and not thinking about the general problem. The number of prompts goes up with the number of variables in the constraint. But the number of possible correct configurations goes up as 2**n -- actually, 3**n because we have trits. ??? No. You propmt only one invalid assertion. After you this prompt you continue to validate rules and you will maybe prompt for another invalid rules. But these invalid rules are generally infrequent. Thus in my proposal the number of questions on the *worste* case are equal to your proposal (rm configuration an reconfigure it again, the vi methods is not serious). What you're saying, in effect, is that if f is number of frozen variables in the constraint then the configurator ought to generate 3 ** (n - f) possible correct models and prompt for one of them. Since f typically equals just 1 that number goes up really fast with n. And what if one of the variables in the constraint is of integer or string type? In that case the number of possible models to be prompted for is effectively infinite. (Finite but very very large). It is very unlikely to have constraint on string or on integer. But anyway, where is the problem? You simple ask the new value of this symbol. You are proposing an interface that will handle easy cases but blow up in the user's face in any hard one. That's poor design, frustrating the user exactly when he/she most needs help. But how do you help such users? Telling them to use vi? Broken configuration will always exist (with generally few errors). Surelly also you produce incorrect configuration. (You can garantee that configuration for CML2 for kernel 2.4.3 is fully compatible with rules you use for 2.4.4? and for the 2.5.x? We make always error. But if you don't correct the behaviour of oldconfig we will tend not to correct CML2 rules, because it can broke our configuration (and we will prefer a incorrect but working configuration that a correct configuration (but that requires a complete reconfiguration, or some luck with vi) giacomo PS: I think you missundestood my previous email. No autimatic recovery of broken configuration, but it is need a usefull tool to produce a valid configuration from an (maybe) invalid or old configuration. In a manual manner. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
