Re: Timestamps in static libraries
On Oct 5, 2010, at 2:47 PM, Erik Cederstrand wrote: > Den 05/10/2010 kl. 15.59 skrev Erik Trulsson: > On Tue, Oct 05, 2010 at 03:28:36PM +0200, Erik Cederstrand wrote: >>> >>> I was using bsdiff for the compression and found out >>> that md5 sums of static libraries (.a files) in /usr/lib and >>> /usr/local/lib didn't match between jails, even though the source >>> code used to create the jails hadn't changed. One of my goals is to >>> detect which files in a distribution change between two commits. >>> >>> It turns out that timestamps are stored in the library: >> > > Thanks, that was very helpful. It seems I can at least normalize the .a files > ... Unfortunately it seems there's still a creation time of the archive > itself that I cant alter using the above, so the md5 sums still don't match: > > % diff mod.strings orig.strings > 2c2 > < / 1286312209 0 0 0 958 ` > --- >> / 1269146263 0 0 0 958 ` That's the timestamp on the pseudo-entry used to store the archive symbol table. (GNU/SysV ar files use a pseudo-entry named "/" to store the symbol table. Since '/' is added to end of names in this format, this is essentially an entry with an empty name.) The current ar code generates this entry and sets the timestamp around line 624 of usr.bin/ar/write.c. As far as I can tell, ar itself doesn't care about the timestamp here; it's possible that ranlib or ld do care. If they don't, we could set this timestamp to zero always. Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: breaking the crunchgen logic into a share/mk file
On 5 October 2010 11:19, Garrett Cooper wrote: > Hi Adrian, > Is there a functional difference between the original file and > bsd.crunchgen.mk ? Only the bare minimum needed to make it useful: * added shared library as well as fully static library support * added a method for listing sourcedirs that need "build-tools" target built first. These were hard-coded. I specifically didn't want to introduce too much in this first pass. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
issue with unsetting 'arch' flag
hi there, i think the following example shows the problem better than a long explanation: `touch ftest && chflags arch ftest && chflags -vv 0 ftest`. ^^non-root ^^root^^non-root chflags claims to have cleared the 'arch' flag (which should be impossible as non-root user), but indeed has done nothing. i've tried the same with 'sappnd' and that works as can be expected. The issue was confirmed to exist in HEAD (me), stable/8 (pgollucc1, jpaetzel) and stable/7 (nox). On stable/6 it does NOT exist (jpaetzel). chflags properly fails with EPERM. cheers. alex -- a13x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Thread priorities
On 10/5/10 2:19 PM, Eknath Venkataramani wrote: In kern_switch.c, It is said that, Free threads are 'preassigned' to the KSEs. and that the KSEs derive their priority from threads and are put on the run queue. 1. Where do the threads receive their priorities from? from the process they are assigned to. 2. Does it recieve the priority from the KSEG? well, it got some modification of it's priority due to KSEG behaviour. (or at least that was the plan) this must be very old code because ksegs were removed some time ago. please ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Improve OptionalObsoleteFiles.inc
On Tue, 5 Oct 2010, Alexander Leidinger wrote: We do not have a target which allows to go to src/bin/XXX and run "make deinstall" or similar. What is correctly written in this thread is that "make check-old" and "make delete-old" (and "make delete-old-libs") is supposed to do what you want (given that there is already support in the src to exclude this part of FreeBSD during installation). The most up-to-date version is in -current, I do not know about the stable branches (I do not monitor if people which change the corresponding file have merged the changes to stable branches or not). What may not be 100% correct in src is the list of files to delete (= a bug). For this the suggestion in the thread is also correct, if there is something which does not work please send a PR. This would be more accurate and require less maintenance if OptionalObsoleteFiles.inc were auto-generated ala genplist. Don't know if that's practical, just wanted to suggest it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
kernel micro-benchmarking framework
Hi all,
based on a work of rwatson@ about micro-benchmarking,
I managed to have a kernel module that exposes some sysctls.
Reading sysctl associated to test start the benchmark and print the results.
The code is split up in this way:
test.h, test.c
where the infrastructure work lives.
test_sync_timing.c
test_mem_timing.c
where the actual micro-benchmarks live:
I wrote some macros to simplify adding more benchmarks. (test.h)
The idea is to have a struct for every benchmark/test
struct timing_proc {
void (*setup)(void *); /* called before
starting timing */
void (*test)(void *); /* what we want
microbenchmark */
void (*tear_down)(void *); /* called after the end of timing */
void *args; /* pointer passed to
the above funcs */
};
and let an agnostic code deals with it.
Every test can specify a setup and tear_down function for
allocate/deallocate resources and a test function to benchmark things.
The great difference with Robert's code is that the test function cannot be
inline as it's a pointer to function. I don't know if that could
influence the results.
The test function is called with interrupt disabled.
We could further extent this framework to add regression test support.
You could get the code here:
http://www.trematerra.net/patches/timing.tbz
Feedback and reviews are welcome.
Thanks
--
Gianni
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Timestamps in static libraries
Den 05/10/2010 kl. 15.59 skrev Erik Trulsson: > On Tue, Oct 05, 2010 at 03:28:36PM +0200, Erik Cederstrand wrote: >> Hello hackers, >> >> I got reminded of a problem I had a couple of years back compressing >> FreeBSD jails. I was using bsdiff for the compression and found out >> that md5 sums of static libraries (.a files) in /usr/lib and >> /usr/local/lib didn't match between jails, even though the source >> code used to create the jails hadn't changed. One of my goals is to >> detect which files in a distribution change between two commits. >> >> It turns out that timestamps are stored in the library: > > Yes, they are. That is because the file format used for static > libraries include a timestamp for each object file stored in the > archive. > > You can use 'ar -tv /PATH/TO/LIBRARY/libfoo.a' to get a list of the > objects stored in the archive and the corresponding timestamps. > > See the ar(5) manpage for a description of the file format, and the > ar(1) manpage for information on how to manage such files. Thanks, that was very helpful. It seems I can at least normalize the .a files using something like the following to weed out timestamps and uid/gid: % ar -x /usr/lib/libfetch.a % chown 0:0 * % touch -t 19700101 * % ar -r libfetch.a `ar -t /usr/lib/libfetch.a` The above takes ca. 10 seconds for all static libraries on my aging machine, which is OK in my case. Unfortunately it seems there's still a creation time of the archive itself that I cant alter using the above, so the md5 sums still don't match: % diff mod.strings orig.strings 2c2 < / 1286312209 0 0 0 958 ` --- > / 1269146263 0 0 0 958 ` Using Python to replace 1286312209 with 1269146263 in the binary file now gives me matching md5 sums. It seems a bit complicated just to get rid of some timestamps, though. Thanks, Erik
Thread priorities
In kern_switch.c, It is said that, Free threads are 'preassigned' to the KSEs. and that the KSEs derive their priority from threads and are put on the run queue. 1. Where do the threads receive their priorities from? 2. Does it recieve the priority from the KSEG? -- Eknath Venkataramani ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Add -lssp_nonshared to GCC's LIB_SPEC unconditionally
Hi Kib,
On Mon, Sep 27, 2010 at 06:44:57PM +0300, Kostik Belousov wrote:
> Hardcoding /usr/lib as the path to the library in the script looks
> problematic. For the buidlworld, you are linking resulting binaries
> with the host library, instead of the buildworld-produced one. For
> lib32, it makes non-working combination of 32/64 bit.
Sorry for the late reply, but I had to collect various evidences for my
sayings and my development machine is reaaally slow.
In fact it seems the toolchain built for buildworld contains a ld(1)
binary which invariably bases lookups for libraries in ${WORLDTMP}, even
in case of an absolute path. I have two evidences of this:
- Putting /usr/obj/usr/src/tmp/usr/lib/libssp_nonshared.a in
/usr/obj/usr/src/tmp/usr/lib/libc.ld leads toolchain's ld(1) to use
/usr/obj/usr/src/tmp/usr/obj/usr/src/tmp/usr/lib/libssp_nonshared.a;
- I also verified this with a hand-wrought opensnoop-like DTrace script.
If it's enough for you, can you please go forward and commit my patch?
I can make a cleaner one if you want.
Thanks.
Regards,
--
Jeremie Le Hen
Humans are born free and equal. But some are more equal than others.
Coluche
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysctl for querying kmem_map->size
on 30/09/2010 20:17 Andriy Gapon said the following: > > Here's a patch that adds a sysctl for querying kmem_map->size, which may be > useful > for system state/resources monitoring: > http://people.freebsd.org/~avg/sysctl-kmem_map_size.diff > > I am quite unsure about sizeof(kmem_map->size) == sizeof(int) hack, but I > couldn't > think of other way to decide whether to use SYSCTL_ADD_UINT or > SYSCTL_ADD_ULONG > depending on real type behind vm_size_t. Here's an updated patch: http://people.freebsd.org/~avg/sysctl-kmem_map_size2.diff The new code wraps kmem_map->size into SYSCTL_PROC() to handle vm_size_t type differences for different platforms. The idea is suggested by Ed Maste. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Timestamps in static libraries
On Tue, 5 Oct 2010, Joerg Sonnenberger wrote: On Tue, Oct 05, 2010 at 03:28:36PM +0200, Erik Cederstrand wrote: I'm wondering if this is necessary, or if this can possibly be turned of with a knob somewhere. Newer binutils got a flag after a discussion about this and related issues in NetBSD. It basically stores 0 for the uid/gid/time fields. This also came up recently in the context of producing static libraries from object files with large uid's (such as in AFS). A couple of patches to ar(1) and libarchive were bandied about, though I don't think Tim Kientzle has committed any of them, yet. (As it turns out, I may also need to patch ranlib(1) in order to get a complete buildworld in my large-uid environment, and possibly other things.) -Ben Kaduk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Timestamps in static libraries
On Tue, Oct 05, 2010 at 03:28:36PM +0200, Erik Cederstrand wrote: > I'm wondering if this is necessary, or if this can possibly be turned > of with a knob somewhere. Newer binutils got a flag after a discussion about this and related issues in NetBSD. It basically stores 0 for the uid/gid/time fields. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Timestamps in static libraries
On Tue, Oct 05, 2010 at 03:28:36PM +0200, Erik Cederstrand wrote: > Hello hackers, > > I got reminded of a problem I had a couple of years back compressing > FreeBSD jails. I was using bsdiff for the compression and found out > that md5 sums of static libraries (.a files) in /usr/lib and > /usr/local/lib didn't match between jails, even though the source > code used to create the jails hadn't changed. One of my goals is to > detect which files in a distribution change between two commits. > > It turns out that timestamps are stored in the library: Yes, they are. That is because the file format used for static libraries include a timestamp for each object file stored in the archive. You can use 'ar -tv /PATH/TO/LIBRARY/libfoo.a' to get a list of the objects stored in the archive and the corresponding timestamps. See the ar(5) manpage for a description of the file format, and the ar(1) manpage for information on how to manage such files. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Improve OptionalObsoleteFiles.inc
Quoting rank1see...@gmail.com (from Tue, 05 Oct 2010 14:48:23 +0200): - Original Message - From: Alexander Leidinger To: Gonzalo Nemmi Cc: freebsd-hackers@freebsd.org Date: Tue, 05 Oct 2010 11:34:23 +0200 Subject: Re: Improve OptionalObsoleteFiles.inc As the one who wrote the functionailty: The delete-old stuff is designed to delete stuff which was installed by an installworld (or similar) before, but is not installed by installworld (or similar) now. As there may be old programs around which depend upon such a file or directory, you have to explicitely tell if you are ok to delete it or not (it is the responsability of the administrator to make sure everything is OK). If you are sure no program still depends upon it (make check-old), you can specify -DBATCH_DELETE_OLD_FILES to delete everything without being asked (see "man build"). As we've read in this thread that the files I would like to keep are not installed by an installworld if the corresponding option is specified, the patch is 100% correct and Peter and you want to use delete-old for something it was not designed for (and I should discuss somewhere else to install the files I talked about even if the corresponding option is specified). ~2 months ago I've opened a thread called: Deinstalling parts of base Take a look here: http://forums.freebsd.org/showthread.php?t=17860 We do not have a target which allows to go to src/bin/XXX and run "make deinstall" or similar. What is correctly written in this thread is that "make check-old" and "make delete-old" (and "make delete-old-libs") is supposed to do what you want (given that there is already support in the src to exclude this part of FreeBSD during installation). The most up-to-date version is in -current, I do not know about the stable branches (I do not monitor if people which change the corresponding file have merged the changes to stable branches or not). What may not be 100% correct in src is the list of files to delete (= a bug). For this the suggestion in the thread is also correct, if there is something which does not work please send a PR. It would be great if you specify which files are left over or even better provide a patch for the /usr/src/tools/build/mk/OptionalObsoleteFiles.inc file (it's not hard to add files there, you just have to follow the real-world-examples there). Attention: only stuff which is already supported to be skipped during installworld belongs there. So if you specify WITHOUT_XXX and you do an installworld into a scratch-area (with "make installworld DESTDIR=/path/to/scratch" it shall not show up there). Bye, Alexander. -- Haste makes waste. -- John Heywood http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Timestamps in static libraries
Hello hackers, I got reminded of a problem I had a couple of years back compressing FreeBSD jails. I was using bsdiff for the compression and found out that md5 sums of static libraries (.a files) in /usr/lib and /usr/local/lib didn't match between jails, even though the source code used to create the jails hadn't changed. One of my goals is to detect which files in a distribution change between two commits. It turns out that timestamps are stored in the library: # strings DIR1/usr/lib/libfetch.a > tmp1 # strings DIR2/usr/lib/libfetch.a > tmp2 # diff tmp1 tmp2 2c2 < / 1200728973 0 0 0 954 ` --- > / 1200723259 0 0 0 954 ` 57c57 < file.o/ 1200728973 0 0 100644 2356 ` --- > file.o/ 1200723259 0 0 100644 2356 ` 86c86 < http.o/ 1200728973 0 0 100644 17180 ` --- > http.o/ 1200723258 0 0 100644 17180 ` [...] I'm wondering if this is necessary, or if this can possibly be turned of with a knob somewhere. Thanks, Erik
Re: Improve OptionalObsoleteFiles.inc
- Original Message - From: Alexander Leidinger To: Gonzalo Nemmi Cc: freebsd-hackers@freebsd.org Date: Tue, 05 Oct 2010 11:34:23 +0200 Subject: Re: Improve OptionalObsoleteFiles.inc > Quoting Gonzalo Nemmi (from Tue, 5 Oct 2010 > 01:30:00 +0200): > > > On Mon, Oct 4, 2010 at 5:31 PM, Paul B Mahol wrote: > >> On 10/4/10, Peter Pentchev wrote: > >>> On Mon, Oct 04, 2010 at 11:01:45AM +, Paul B Mahol wrote: > On 10/4/10, Alexander Leidinger wrote: > > > At least status-mailq is still useful with other MTAs, e.g. if you use > > postfix (and assuming the mailwrapper is configured correctly), this > > should still work. Depending on the setup of the aliases, > > backup-aliases will still work too. I haven't checked for the other > > ones. > > If you want to keep some "old" files, you just need to press `n' instead > of `y' > when deleting files. You are not forced to run make delete-old at all. > >>> > >>> On the other hand, doing this (skipping those files) on each and every > >>> system > >>> update (say, on a development or testing machine) could get a bit... > >>> boring > >>> - > >>> not to mention that at some point you'll learn to "oh, just say no", and > >>> then > >>> forget to remove something important. > >> > >> Oh! I see... I want it in black. > > > > Hold your horses there ... get it to work as expected and then, > > _and_only_then_ you can start raising your finger and accussing poster > > of bikesheding ... > > As it stands, _it_sucks_ and I have already pointed it out before > > without much success (something as useless as telnet wasn´t deleted a > > not so long time ago) ... Peter Pentchev´s point was a completely > > valid one. > > As the one who wrote the functionailty: The delete-old stuff is > designed to delete stuff which was installed by an installworld (or > similar) before, but is not installed by installworld (or similar) > now. As there may be old programs around which depend upon such a file > or directory, you have to explicitely tell if you are ok to delete it > or not (it is the responsability of the administrator to make sure > everything is OK). If you are sure no program still depends upon it > (make check-old), you can specify -DBATCH_DELETE_OLD_FILES to delete > everything without being asked (see "man build"). > > As we've read in this thread that the files I would like to keep are > not installed by an installworld if the corresponding option is > specified, the patch is 100% correct and Peter and you want to use > delete-old for something it was not designed for (and I should discuss > somewhere else to install the files I talked about even if the > corresponding option is specified). > > Bye, > Alexander. ~2 months ago I've opened a thread called: Deinstalling parts of base Take a look here: http://forums.freebsd.org/showthread.php?t=17860 Domagoj ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: page table fault, which should map kernel virtual address space
On Mon, Oct 4, 2010 at 2:03 AM, Alan Cox wrote:
> On Thu, Sep 30, 2010 at 6:28 AM, Svatopluk Kraus wrote:
>>
>> On Tue, Sep 21, 2010 at 7:38 PM, Alan Cox wrote:
>> > On Mon, Sep 20, 2010 at 9:32 AM, Svatopluk Kraus
>> > wrote:
>> >> Beyond 'kernel_map', some submaps of 'kernel_map' (buffer_map,
>> >> pager_map,...) exist as result of 'kmem_suballoc' function call.
>> >> When this submaps are used (for example 'kmem_alloc_nofault'
>> >> function) and its virtual address subspace is at the end of
>> >> used kernel virtual address space at the moment (and above 'NKPT'
>> >> preallocation), then missing page tables are not allocated
>> >> and double fault can happen.
>> >>
>> >
>> > No, the page tables are allocated. If you create a submap X of the
>> > kernel
>> > map using kmem_suballoc(), then a vm_map_findspace() is performed by
>> > vm_map_find() on the kernel map to find space for the submap X. As you
>> > note
>> > above, the call to vm_map_findspace() on the kernel map will call
>> > pmap_growkernel() if needed to extend the kernel page table.
>> >
>> > If you create another submap X' of X, then that submap X' can only map
>> > addresses that fall within the range for X. So, any necessary page
>> > table
>> > pages were allocated when X was created.
>>
>> You are right. Mea culpa. I was focused on a solution and made
>> too quick conclusion. The page table fault hitted in 'pager_map',
>> which is submap of 'clean_map' and when I debugged the problem
>> I didn't see a submap stuff as a whole.
>>
>> > That said, there may actually be a problem with the implementation of
>> > the
>> > superpage_align parameter to kmem_suballoc(). If a submap is created
>> > with
>> > superpage_align equal to TRUE, but the submap's size is not a multiple
>> > of
>> > the superpage size, then vm_map_find() may not allocate a page table
>> > page
>> > for the last megabyte or so of the submap.
>> >
>> > There are only a few places where kmem_suballoc() is called with
>> > superpage_align set to TRUE. If you changed them to FALSE, that is an
>> > easy
>> > way to test this hypothesis.
>>
>> Yes, it helps.
>>
>> My story is that the problem started up when I updated a project
>> ('coldfire' port)
>> based on FreeBSD 8.0. to FreeBSD current version. In the current version
>> the 'clean_map' submap is created with superpage_align set to TRUE.
>>
>> I have looked at vm_map_find() and debugged the page table fault once
>> again.
>> IMO, it looks that a do-while loop does not work in the function as
>> intended.
>> A vm_map_findspace() finds a space and calls pmap_growkernel() if needed.
>> A pmap_align_superpage() arrange the space but never call
>> pmap_growkernel().
>> A vm_map_insert() inserts the aligned space into a map without error
>> and never call pmap_growkernel() and does not invoke loop iteration.
>>
>> I don't know too much about an idea how a virtual memory model is
>> implemented
>> and used in other modules. But it seems that it could be more reasonable
>> to
>> align address space in vm_map_findspace() internally and not to loop
>> externally.
>>
>> I have tried to add a check in vm_map_insert() that checks the 'end'
>> parameter
>> against 'kernel_vm_end' variable and returns KERN_NO_SPACE error if
>> needed.
>> In this case the loop in vm_map_find() works and I have no problem with
>> the page table fault. But 'kernel_vm_end' variable must be initializated
>> properly before first use of vm_map_insert(). The 'kernel_vm_end' variable
>> can be self-initializated in pmap_growkernel() in FreeBSD 8.0 (it is too
>> late),
>> but it was changed in current version ('i386' port).
>>
>> Thanks for your answer, but I'm still looking for permanent
>> and approved solution.
>
> I have a patch that implements one possible fix for this problem. I'll
> probably commit that patch in the next day or two.
>
> Regards,
> Alan
I tried your patch and it works. Many thanks.
Regards, Svata
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Improve OptionalObsoleteFiles.inc
Quoting Gonzalo Nemmi (from Tue, 5 Oct 2010 01:30:00 +0200): On Mon, Oct 4, 2010 at 5:31 PM, Paul B Mahol wrote: On 10/4/10, Peter Pentchev wrote: On Mon, Oct 04, 2010 at 11:01:45AM +, Paul B Mahol wrote: On 10/4/10, Alexander Leidinger wrote: > At least status-mailq is still useful with other MTAs, e.g. if you use > postfix (and assuming the mailwrapper is configured correctly), this > should still work. Depending on the setup of the aliases, > backup-aliases will still work too. I haven't checked for the other > ones. If you want to keep some "old" files, you just need to press `n' instead of `y' when deleting files. You are not forced to run make delete-old at all. On the other hand, doing this (skipping those files) on each and every system update (say, on a development or testing machine) could get a bit... boring - not to mention that at some point you'll learn to "oh, just say no", and then forget to remove something important. Oh! I see... I want it in black. Hold your horses there ... get it to work as expected and then, _and_only_then_ you can start raising your finger and accussing poster of bikesheding ... As it stands, _it_sucks_ and I have already pointed it out before without much success (something as useless as telnet wasn´t deleted a not so long time ago) ... Peter Pentchev´s point was a completely valid one. As the one who wrote the functionailty: The delete-old stuff is designed to delete stuff which was installed by an installworld (or similar) before, but is not installed by installworld (or similar) now. As there may be old programs around which depend upon such a file or directory, you have to explicitely tell if you are ok to delete it or not (it is the responsability of the administrator to make sure everything is OK). If you are sure no program still depends upon it (make check-old), you can specify -DBATCH_DELETE_OLD_FILES to delete everything without being asked (see "man build"). As we've read in this thread that the files I would like to keep are not installed by an installworld if the corresponding option is specified, the patch is 100% correct and Peter and you want to use delete-old for something it was not designed for (and I should discuss somewhere else to install the files I talked about even if the corresponding option is specified). Bye, Alexander. -- Detroit is Cleveland without the glitter. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Improve OptionalObsoleteFiles.inc
Quoting Paul B Mahol (from Mon, 4 Oct 2010 11:01:45 +):
On 10/4/10, Alexander Leidinger wrote:
Quoting Paul B Mahol (from Sun, 3 Oct 2010 13:53:26
+):
Hi,
diff --git a/tools/build/mk/OptionalObsoleteFiles.inc
b/tools/build/mk/OptionalObsoleteFiles.inc
index d3aa4b2..2123107 100644
--- a/tools/build/mk/OptionalObsoleteFiles.inc
+++ b/tools/build/mk/OptionalObsoleteFiles.inc
@@ -141,6 +141,7 @@ OLD_FILES+=usr/share/man/man8/authpf.8.gz
.endif
.if ${MK_BIND} == no
+OLD_FILES+=etc/periodic/daily/470.status-named
If bind is installed from ports instead, this file could be useful, isn't
it?
OLD_FILES+=usr/bin/dig
OLD_FILES+=usr/bin/host
OLD_FILES+=usr/bin/nslookup
[...]
@@ -1976,6 +1998,11 @@ OLD_FILES+=usr/share/man/man8/rtquery.8.gz
.endif
.if ${MK_SENDMAIL} == no
+OLD_FILES+=etc/periodic/daily/150.clean-hoststat
+OLD_FILES+=etc/periodic/daily/210.backup-aliases
+OLD_FILES+=etc/periodic/daily/440.status-mailq
+OLD_FILES+=etc/periodic/daily/460.status-mail-rejects
+OLD_FILES+=etc/periodic/daily/500.queuerun
OLD_FILES+=bin/rmail
OLD_FILES+=usr/bin/vacation
OLD_FILES+=usr/include/libmilter/mfapi.h
At least status-mailq is still useful with other MTAs, e.g. if you use
postfix (and assuming the mailwrapper is configured correctly), this
should still work. Depending on the setup of the aliases,
backup-aliases will still work too. I haven't checked for the other
ones.
If you want to keep some "old" files, you just need to press `n'
instead of `y'
when deleting files. You are not forced to run make delete-old at all.
I know, I wrote delete-old and related ones. :)
When installing world in new environment such files are not installed anyway.
That's an argument (and your patch is OK). So I should discuss
(somewhere else) if this needs to be changed.
Bye,
Alexander.
--
Stone's Law:
One man's "simple" is another man's "huh?"
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
