From: "Giacomo A. Catenazzi" <cate@student.ethz.ch>
To: "Eric S. Raymond" <esr@snark.thyrsus.com>
Cc: linux-kernel@vger.kernel.org, linux-kbuild@torque.net
Subject: Re: [KBUILD] How do we handle autoconfiguration?
Date: Wed, 27 Dec 2000 12:14:36 +0100 [thread overview]
Message-ID: <3A49CF1C.19A0FB55@student.ethz.ch> (raw)
In-Reply-To: <200012262313.eBQNDBi07719@snark.thyrsus.com>
"Eric S. Raymond" wrote:
>
> I backed away from this because Giacomo Catenazzi told me he was
> working on a separate autoconfigurator that would generate config
> files in CML1 format. That's a cleaner design -- one would run his
> autoconfigurator and then import the resulting config into the CML2
> configurator as frozen (immutable) symbols. Giacomo, what's the state
> of your project?
Status:
Now I can detect most of modern hardware, and also some software
protocols.
My autoconfiguration only in few case say N, because is it difficult
to say: you don't need this drivers (e.g. the Matrox Millemium
include a list of PCI devices, but my card is not included,
but anyway, the driver works, because after the check of PCI ID, it
do further checks on other video PCI class).
I'm happy with the autodetection. I need some other software protocols
to detect, but it is difficult to distinguish: "need protocols" and
"protocols included in actual kernel (but nobody will use it)".
I've difficult to merge with the CML1/2:
In CML2-0.8.3 the include frozen flag (-I) is broken, and
also the new -W flag is broken, thus no real test.
CML2-0.9.0 need Python 2, which is not in the debian unstable
distribution, and I had no time to compile myself.
CML1: There is to many not answered question (most not important)
thus it has little value in use with make oldconfig.
(CML2 has a "oldmenuconfig and oldxconfig")
Thus I should modify the Configure files, but with CML2....
I will also add a NOVICE/NORMAL/EXPERT configuration menu,
to include ELF, COFF, IPC, SHM, ... . It is in project since
lots of days, but ELM, COFF, ELF64 are processor dependent,
and I don't find (yet) a clean method to include this
dependence (CML2).
giacomo
TODO: a correct/complete autodetection of CPU.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-12-27 11:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-26 23:13 How do we handle autoconfiguration? Eric S. Raymond
2000-12-27 9:57 ` Kai Henningsen
2000-12-27 11:14 ` Giacomo A. Catenazzi [this message]
2000-12-27 14:27 ` [KBUILD] " Giacomo A. Catenazzi
2000-12-27 16:10 ` Eric S. Raymond
-- strict thread matches above, loose matches on Subject: below --
2000-12-26 23:18 Eric S. Raymond
2000-12-27 10:31 ` [KBUILD] " Giacomo A. Catenazzi
2000-12-27 0:52 Michael Elizabeth Chastain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A49CF1C.19A0FB55@student.ethz.ch \
--to=cate@student.ethz.ch \
--cc=esr@snark.thyrsus.com \
--cc=linux-kbuild@torque.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox