Re: A newbie's view

["Seth M. Landsman" <seth@job.cs.brandeis.edu>]

On Fri, Jan 29, 1999 at 04:32:42AM +0100, Kenneth Skaar wrote:
> 
> Seem like you didnt read the devlopment page very well. since most of what
> you list _are_ things they plan do implement.

	No, I didn't go through it all that carefully.  And I never said
that the projects were incompatible, my only point is that the focus is
fundementally different.  I'm looking to technically improve the build
process, while I think that LKM is looking to replace it with something
more user friendly.  The two are compatible goals, but not identical.

> 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.

	I think that the LKM Kernel Tracker is overkill for what is
necessary.  Esp. in a situation where I might have 40 different machines
with different configurations.  I'm not necessarily going to have all of
them in the DB, nor am I necessarily going to be able to pick the right
one.  On top of that, this seems like a solution that is more complex than
necessary.  There are plenty of places where this idea is a good one,
however, a /proc/config or something similar is a better solution, IMO.

> > 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.

	I did not see that bullet.  I must have missed it.  

> > 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 

<snip>

	This is a good idea.  However, it isn't the problem I'm going for.
I think that the defaults that the kernel ships with are not technically
the best.  i.e., there are a number of bullets with the help text saying
"enable this", yet it defaults to disabled.

> > 	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.

	That's fine.  I'm not saying that the LKM should get killed.  I'm
trying for a discussion of what we'd like to see done to the configuration
and build process, which has not reached the same level of technical
excellence the kernel has.
	It is possible that this is stuff which all belongs in the LKM,
but the right solution is not to kill this thread off as being irrelevent
or (gasp) a competitor to another free software project.

> > 	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?)

	I don't know about this.  You're assuming an awful lot.  I know I
would strongly prefer a process by which I can run a script via ssh to
configure several machines.  I know many other sysadmins who wish for the
same.  LKM is fundementally different here.  I'm looking for a way to
ensure correctness in the kernel building process, not a prettier
interface.
	Writing a good commandline interface for an existing X based app
isn't that easy.

> > > 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.

	I think you are incorrect here. 

> 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.

	I think you missed the entire point of my post.  I'm looking for
(a) a way to build a more correct kernel and (b) a way to build a more
automatic kernel.  This gives more user friendliness as a side effect, but
not as its chief goal.  

-Seth

--
"It is by will alone I set my mind in motion"
-
Linux-future: thinking about the future of the Linux kernel
http://humbolt.nl.linux.org/lists/