This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: config tools
- To: danc at iobjects dot com
- Subject: Re: [ECOS] config tools
- From: Bart Veer <bartv at redhat dot com>
- Date: Fri, 10 Aug 2001 19:09:33 +0100
- Cc: ecos-discuss at sources dot redhat dot com
- References: <D8DFF0AFE792914996F997E68FEC3A48F320@bunker.iobjects.com>
- Reply-To: bartv at redhat dot com
>>>>> "Dan" == Dan Conti <danc@iobjects.com> writes:
<snip>
>> Hence the next time the user starts to edit the configuration
>> the savefile is an accurate representation of the current
>> state. There have been debates in the past about exactly which
>> ecosconfig operations should and should not cause an updated
>> ecos.ecc file to be written out, but no consensus.
Dan> This seems to all make sense, assuming the contents of the
Dan> .ecc have changed. However, my configurations are being
Dan> generated by the gui tool, so they dont need to be modified
Dan> or updated.
Probably the best solution would be for ecosconfig to write to a
temporary file and then diff the new and old versions of ecos.ecc,
only overwriting the old version when necessary. Or even better,
construct the new copy in memory first.
>> So having a read-only ecos.ecc file is unexpected. However, I
>> have just tried a little experiment doing a chmod -w on
>> ecos.ecc in an existing build tree and it does not behave too
>> badly:
>>
>> $ ecosconfig tree
>> Unable to open file ecos.ecc
>> couldn't open "ecos.ecc": permission denied
>>
>> ecosconfig exits before updating the build tree, and the error
>> message is unclear that the problem is with write-access to the
>> savefile so it should be improved, but I do not see the strange
>> behaviour you have reported. If I try to run this in a new
>> directory after copying across an existing ecos.ecc I get the
>> same error.
Dan> I should explain now that i'm using cygwin (i just noticed i
Dan> hadn't mentioned that). I'm using --no-resolve; if i turn
Dan> that off, i get a spew of messages such as the following:
Dan> U CYGSEM_KERNEL_SCHED_TIMESLICE_ENABLE, new inferred value 1
Dan> U CYGBLD_ISO_STDIO_FORMATTED_IO_HEADER, new inferred value
Dan> <cyg/libc/stdio/stdio.h>
Dan> U CYGBLD_ISO_STDIO_FILEACCESS_HEADER, new inferred value
Dan> <cyg/libc/stdio/stdio.h>
Dan> U CYGSEM_KERNEL_SCHED_ASR_GLOBAL, new inferred value 1
Some of these look familiar: there was a problem in the GUI configtool
in that it was failing to resolve some conflicts that ecosconfig could
resolve automatically. Hence the savefile generated by the GUI was not
conflict-free, and ecosconfig resolves the problems. The most recent
version of the config tool has a fix for this. Note that these
messages are not errors, they are just informative messages to tell
you about changes in the configuration. The --quiet option should
suppress that output.
However if this is really what is happening then I would expect the
updated ecos.ecc file to be different from the original.
Bart