Re: A newbie's view

[Kenneth Skaar <Kenneth.Skaar@runit.sintef.no>]

Seem like you didnt read the devlopment page very well. since most of what
you list _are_ things they plan do implement.

On Thu, 28 Jan 1999, Seth M. Landsman wrote:

> 
> 	It does not seem like this is being worked on by the LKM project,
> after looking through the web page.  
> 
> 	Okay, here's a list of what I want :
> 
> o grok from a currently running kernel the entire .config or pieces of it
> (this has been talked to death on linux-kernel)
If this means reading from e.g. /proc/config the current configuration,
yes this needs to be in the kernel. If not the Kernel Tracker DB of LKM
seems like a good idea of how too keep track of current and previous
configurations.

> 
> o grok from hardware probing various important addresses (i.e., I/O of the
> sound card)

From LKM development page:
In addition, I am looking at several Plug 'n' Play kernel tools to maybe
integrate into the LKM to enable it to probe for and configure hardware
devices automatically.
 
> o a more reasonable set of defaults (perhaps based on above hardware
> probing)
Or you could even choose from a set of "profiles":(again from LKM dev.
page)

Kernel Profiles 

When configuring machines to perform 'standard' tasks such as a mailhost,
ISP box, database server, graphics workstation or multimedia system, you
may select a kernel profile that suits the machines intended use. If, for
instance, you had just installed Linux on a PC that you were going to use
solely as a database server, you would select a database kernel profile
which will pre-configure the kernel options needed to support a database
server set-up, then manually customise the remainder of the kernel. A
kernel profile will save you time but still offer the flexibility for
customisation and configurability.

> > o big obvious warnings if the user turns off a "necessary to survive"
> option, like ELF support

This would of cource be a small addition to LKM. Send the author a mail,
suggesting this to him.
> 
> o big obvious warnings if the user turns off a driver that was detected in
> hardware or turns on a driver that was not.

I guess this also goes in the catagory of small changes.
> 
> o some sort of `make test` that make sure the kernel is valid and has a
> decent chance of booting the machine in question.
Maybe you see a reason I don't for why LKM cant accomplish this. 
> 
> 	It doesn't seem that LKM does most of these.  
> 
LKM doesnt currently do much at all. But it they seem to have a good idea
of what they want it do do, and they are probarly open for input on things
they didnt think about.

> 	Furthermore, anything that is done *SHOULD WORK FROM THE
> COMMANDLINE*.  I want to ssh to my router and recompile a kernel without
> having to forward an X session.  LKM might be something we can merge with
> or can use whatever is done, but LKM itself is unacceptable because it is
> only X based.
> 
OK, this is personal preferences. But I think the majority of _users_
would want a nice X-interface. However, adding commandline interface to a
X-app is easier than the other way around.(btw, did you look at the remote
building option they were thinking about? Could this solve your router
problem?)

> > Anyway, IMHO keeping a "user" app like this out of the kernel source 
> > tree is a _good_ idea. 
> 
> 	Some of this would be such an integral part of the build process
> that it would have to be in the source tree, I think.
> 
You might be right there. On the other hand, much of it has nothing to do
with the kernel at all(all UI stuff, DB stuff, patch manager, some of the
"intelligence"). Maybe a "combo" solution, where the kernel shipped with
some "description" files, telling the LKM what it need to know about this
kernel, would work.

Im sorry if I stepped on anybody's toe's her. This thread seemed to
indicate a need for a more user-friendly configuration process, and the
LKM seems to be just that. It might not be the ultimate solution, but as
far as I can see, it is a step in the right direction.

Kenneth


-
Linux-future: thinking about the future of the Linux kernel
http://humbolt.nl.linux.org/lists/