Very Computer

Hi folks,

I'm currently trying to figure out how the linux kernel for embedded
systems (uCLinux) can be stored in a CVS repository efficiently. My plan is
to use following configuration.

o one common installation of linux in /opt/uCLinux-2.4
o symlinking all files of /opt/uCLinux-2.4/* to ~/src/linux/*
o adding my architecture dependent source files and the kernel
configuration files .config and include/linux/autoconf.h to ~/src/linux

Then I would be able to "cvs import" my ~/src/linux directory and only
storing my changed files as cvs doesn't knows about links. This would
improve CVS speed very much as it doesn't has to manage ~100MB source files.
Patches to the original kernels could be applied more easily, too.

My problem is that some source files are being touch'ed by make (e.g.
include/config/MARKER). Other files as linux/drivers/char/defkeymap.c are
being automatically generated. Symlinking them would therefore change
files outside my CVS control.

Can anyone please help me out why these files are modified? Is it possible
to avoid this or how can I get a complete list of this files? I know that
the Elinos distribution has succeeded in modifiying the buildflow to
support this, but I don't know what they have done in detail.

Thanks in advance,
Markus Pietrek

Thank you. But perhaps my question was a little bit unaccurate. The problem
is not using CVS (then I would be in the wrong newsgroup). But a kernel
configuration and make modifies and touches source files and I have no
overview why and what files exactly these are. Therefore I can't install
just one installation of uClinux-2.4 in one path and maintain our changes
at a different location.

Quote:> Btw: what's the status of your uClinux-2.4 port to the Net+ARM platform?
> Does it work?

You are well informed :-) We haven't tried the port yet as we want to set
up our infrastructure first. But we can keep you informed.

Bye,
Markus Pietrek

I'm still not sure if I understand you correctly. The Right Way To Go
(TM) would IMHO be that if you make changes to the original uClinux code
make them available as a patch, referring to which version the patch
applies. Feed back as much code to the project as possible and try to
integrate it to the main tree. If you have stuff that can be turned on
and of make configure options. If you simply want to be sure that once
you have customized a tree for one customer and at a later time you want
to have exactly the same tree just apply the same patches to the same
kernel, save your .config file, 'make oldconfig' and be happy.

Quote:> > Btw: what's the status of your uClinux-2.4 port to the Net+ARM platform?
> > Does it work?

> You are well informed :-)

Always :-)

Quote:> We haven't tried the port yet as we want to set up our infrastructure
> first.

I found it very, hmm, unelegant that you don't have modules available
under uClinux 2.0, which makes development very difficult. Having a 2.4
kernel available would be a great improvement.

Quote:> But we can keep you informed.

Would be great.

Robert
--  
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+