Re: [ANNOUNCE] Framework for automatic Configuration of a Kernel
From: Ahmad Reza Cheraghi (a_r_cheraghi_at_yahoo.com)
Date: 09/29/05
- Previous message: Bartlomiej Zolnierkiewicz: "Re: [PATCH] via82cxxx IDE: Remove /proc/via entry"
- In reply to: Emmanuel Fleury: "Re: [ANNOUNCE] Framework for automatic Configuration of a Kernel"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 29 Sep 2005 00:22:40 -0700 (PDT) To: Emmanuel Fleury <fleury@cs.aau.dk>, Linux Kernel ML <linux-kernel@vger.kernel.org>
--- Emmanuel Fleury <fleury@cs.aau.dk> wrote:
> > I think its good to detect everything, that let a
> > Kernel work after the installation. I mean it the
> > autoconfiguration should't be only for
> Kernel-Hackers.
> > Maybe its good idea to make two type of detection
> >
> > 1. which detects only the HW(For Kernel-Hackers)
> > 2. which detects all the HW and configure
> everything
> > that let the Kernel work.(for beginners)
>
> Why would a beginner compile a kernel ?
Because he wants to be upto date
> I would even say this would be bad if you can avoid
> them to go through
> all the documentations of each option. :)
Why?
> > The best was is to use HW-Detection-Tools that are
> in
> > naked Kernel. But I dont know if is lspci is in
> the
> > Kernel. I mean dmidecode is good for detecting all
> the
> > HW but it has to be installed first. And its no
> good
> > to let the user install first of all some tools so
> the
> > autoconfigure can work.
> > How do we get the HW detected from a naked Kernel
> > without any Distrubotion or whatever.
>
> I doubt we can, at least not in the current status.
>
> And requiring more external tools as lspci,
> dmidecode, etc, is probably
> not right.
>
> More I am thinking of it, more it seems that the
> hardware detection
> softwares (lspci, dmidecode, lsusb) should be
> stripped down and probably
> included somewhere in the kernel tree... But
> wouldn't be too much to pay
> for having an autoconfig ? (I mean maintenance,
> update, debug, ... will
> be way out of the scope of the kernel).
How about making a new project for calling all the
Hardware on the system directly from the I/O and let
then be a part of the Kernel? Its just a suggestion!!
> Did anybody had some though about this previously (I
> tried to look in
> the archive of the LKM but didn't find anything
> relevant) ?
>
> > I dont understand your question. What you mean
> with
> > interfaces??
>
> ncurses, Qt, Gtk, ... (aka menuconfig, xconfig,
> gconfig).
Why should it be in other interfaces?? The plan of the
autoconfig is just to configure the Kernel and nothing
more... What is the advantage of having it in other
interfaces??
Regards
Ahmad Reza Cheraghi
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Bartlomiej Zolnierkiewicz: "Re: [PATCH] via82cxxx IDE: Remove /proc/via entry"
- In reply to: Emmanuel Fleury: "Re: [ANNOUNCE] Framework for automatic Configuration of a Kernel"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
