Re: (void)foo or __unused foo ?
On Jul 27, 2012, at 2:38 AM, Luigi Rizzo wrote:
>
> The alternative way to avoid an 'unused' warning from the compiler
> is an empty statement
>
> (void)foo;
>
> that the compiler hopefully optimizes away.
I learned the void-cast convention many years ago.
I used it throughout the libarchive code and have yet to
run into any problems. I always use it in exactly this form
(with the exact comment here) so that I can easily search
on it:
int foo(int a) {
(void) a; /* UNUSED */
…
}
I agree with PHK that it would be nice to express this
intent in a way that static checkers could verify. I also
agree that having static checkers interpret comments is Evil.
But I have yet to see any alternative that was as
straightforward and widely-supported as this one.
Every other viable alternative seems to require tangled
clumps of macros.
Tim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881
It looks like a case of "lock held during call up the stack". This is bad for so many reasons. It also makes writing correctly locked drivers a pain in the ass as the moment you unlock the driver before calling ether_input() / ieee80211_input(), you allow things to change state. So no, although you shouldn't use long-held locks to protect things, apparently this is all the rage. iwn(4) does this. ath(4) does not. I'm having a right painful time trying to fine-grain lock things. I'm at the point where I'm about to not care, rip out all the locks and replace with a single ATH_LOCK(). Adrian On 27 July 2012 11:47, Dimitry Andric wrote: > On 2012-07-26 17:46, David Wolfskill wrote: >> This is at r238795; cut/paste of backtrace: >> >> KDB: enter: panic >> [ thread pid 12 tid 100026 ] >> Stopped at kdb_enter+0x3d: movl$0,kdb_why >> db> bt >> Tracing pid 12 tid 100026 td 0xc6755000 >> kdb_enter(c0f93c5f,c0f93c5f,c0f91e21,f08398f0,c1825c80,...) at kdb_enter+0x3d >> panic(c0f91e21,c66739a0,c0f20db8,371,c6755000,...) at panic+0x1c4 >> _mtx_lock_sleep(c68b8560,c6755000,c0f20db8,c0f20db8,371,...) at >> _mtx_lock_sleep+0x35e >> _mtx_lock_flags(c68b8560,0,c0f20db8,371,0,...) at _mtx_lock_flags+0xdb >> lem_start(c68ba000,0,c0fa806c,d20,2a,...) at lem_start+0x33 >> if_transmit(c68ba000,c93d9000,6,c6755000,c65da588,...) at if_transmit+0x129 >> ether_output(c68ba000,c93d9000,f0839aa4,0,0,...) at ether_output+0x5df >> arpintr(c93d9000,8,c0f50314,153,0,...) at arpintr+0x108c >> netisr_dispatch_src(7,0,c93d9000,c93d9000,c68ba000,c93d0806) at >> netisr_dispatch_src+0xa7 >> netisr_dispatch(7,c93d9000,c93d9000,10,3,...) at netisr_dispatch+0x20 >> ether_demux(c68ba000,c93d9000,3,0,3,...) at ether_demux+0x133 >> ether_nh_input(c93d9000,c8f012c8,644d6000,c9492d00,0,...) at >> ether_nh_input+0x329 >> netisr_dispatch_src(9,0,c93d9000,e2e,2,1) at netisr_dispatch_src+0xa7 >> netisr_dispatch(9,c93d9000) at netisr_dispatch+0x20 >> ether_input(c68ba000,c93d9000,c0f20db8,e2e,c11454c0,...) at ether_input+0x21 >> lem_intr(c68b6000,8,c0f8e00d,561,0,...) at lem_intr+0x567 >> intr_event_execute_handlers(c11454c0,c6626200,c0f8e00d,561,c6755000,...) at >> intr_event_execute_handlers+0xc5 >> ithread_loop(c6627730,f0839d08,c0f8dd64,3db,0,...) at ithread_loop+0xe2 >> fork_exit(c0a2dcb0,c6627730,f0839d08) at fork_exit+0x7c >> fork_trampoline() at fork_trampoline+0x8 >> --- trap 0, eip = 0, esp = 0xf0839d40, ebp = 0 --- >> db> show locks >> exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xc68b8560) locked @ >> /usr/src/sys/dev/e1000/if_lem.c:1324 >> exclusive sleep mutex em0 (EM Core Lock) r = 0 (0xc68b854c) locked @ >> /usr/src/sys/dev/e1000/if_lem.c:1302 >> db> >> >> I need to head off to a meeting; I can poke at the machine a bit more >> in a couple of hours or so. > > I get the same panic and backtrace here, while running as a VMware > guest. At least, as soon something actually happens with the network. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make release recursion
Hello, On Fri, Jul 27, 2012 at 09:35:13AM +0400, Alexander Pyhalov wrote: > Hello. > I've tried to do "make cdrom" on recent 10-current (svn revision 238763) > and got after day of work: > [...] Could you please retry the cdrom build with NOSRC=yes set? If this does not succeed, could you please provide specific details on how your build environment is set up? While I do recall encountering this in 9-STABLE prior to 9.0-RELEASE, I do not see this happen on 10-CURRENT r237614, and my buildworld/buildkernel on an up-to-date checkout of head is still in progress. Regards, Glen ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881
On 2012-07-26 17:46, David Wolfskill wrote: > This is at r238795; cut/paste of backtrace: > > KDB: enter: panic > [ thread pid 12 tid 100026 ] > Stopped at kdb_enter+0x3d: movl$0,kdb_why > db> bt > Tracing pid 12 tid 100026 td 0xc6755000 > kdb_enter(c0f93c5f,c0f93c5f,c0f91e21,f08398f0,c1825c80,...) at kdb_enter+0x3d > panic(c0f91e21,c66739a0,c0f20db8,371,c6755000,...) at panic+0x1c4 > _mtx_lock_sleep(c68b8560,c6755000,c0f20db8,c0f20db8,371,...) at > _mtx_lock_sleep+0x35e > _mtx_lock_flags(c68b8560,0,c0f20db8,371,0,...) at _mtx_lock_flags+0xdb > lem_start(c68ba000,0,c0fa806c,d20,2a,...) at lem_start+0x33 > if_transmit(c68ba000,c93d9000,6,c6755000,c65da588,...) at if_transmit+0x129 > ether_output(c68ba000,c93d9000,f0839aa4,0,0,...) at ether_output+0x5df > arpintr(c93d9000,8,c0f50314,153,0,...) at arpintr+0x108c > netisr_dispatch_src(7,0,c93d9000,c93d9000,c68ba000,c93d0806) at > netisr_dispatch_src+0xa7 > netisr_dispatch(7,c93d9000,c93d9000,10,3,...) at netisr_dispatch+0x20 > ether_demux(c68ba000,c93d9000,3,0,3,...) at ether_demux+0x133 > ether_nh_input(c93d9000,c8f012c8,644d6000,c9492d00,0,...) at > ether_nh_input+0x329 > netisr_dispatch_src(9,0,c93d9000,e2e,2,1) at netisr_dispatch_src+0xa7 > netisr_dispatch(9,c93d9000) at netisr_dispatch+0x20 > ether_input(c68ba000,c93d9000,c0f20db8,e2e,c11454c0,...) at ether_input+0x21 > lem_intr(c68b6000,8,c0f8e00d,561,0,...) at lem_intr+0x567 > intr_event_execute_handlers(c11454c0,c6626200,c0f8e00d,561,c6755000,...) at > intr_event_execute_handlers+0xc5 > ithread_loop(c6627730,f0839d08,c0f8dd64,3db,0,...) at ithread_loop+0xe2 > fork_exit(c0a2dcb0,c6627730,f0839d08) at fork_exit+0x7c > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xf0839d40, ebp = 0 --- > db> show locks > exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xc68b8560) locked @ > /usr/src/sys/dev/e1000/if_lem.c:1324 > exclusive sleep mutex em0 (EM Core Lock) r = 0 (0xc68b854c) locked @ > /usr/src/sys/dev/e1000/if_lem.c:1302 > db> > > I need to head off to a meeting; I can poke at the machine a bit more > in a couple of hours or so. I get the same panic and backtrace here, while running as a VMware guest. At least, as soon something actually happens with the network. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (void)foo or __unused foo ?
In message <20120727125134.ga58...@onelab2.iet.unipi.it>, Luigi Rizzo writes: >A comment might be used to explain the intention in even more detail: > > (void)foo; /* unused on XyBSD and Babbage-OS */ Comments are noise which compilers and static checkers cannot and should not examine. The intent should be expressed where compilers and static checkers can see it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: use EM_LEGACY_IRQ in if_lem.c ?
Hm. Ok, I wonder whether it's a general case of "touching the hardware too much" versus a more specific case of "all that taskqueue scheduling overhead is killing us in virtualised environments." Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (void)foo or __unused foo ?
I'd rather see a compiler-interpretable "way" of doing this. You could always just use your own for now, until something comes along (like how many #define N(a) there are in the tree, until nitems showed up.) Ie: #define A_UNUSED_Tvoid (A_UNUSED_T) foo; That way (a) it's easy to change with a compile macro change, (b) if it ever clashes, it should be easy enough to rename without having to risk renaming fields you didn't want to, and (c) it's compiler-interpretable. I wonder if bde has any ideas on where a BSD "unused" hint could be stuffed.. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make release recursion
On Fri, Jul 27, 2012 at 8:37 AM, Garrett Cooper wrote: > On Fri, Jul 27, 2012 at 7:26 AM, Oliver Brandmueller wrote: >> Hi, >> >> On Fri, Jul 27, 2012 at 09:35:13AM +0400, Alexander Pyhalov wrote: >>> Hello. >>> I've tried to do "make cdrom" on recent 10-current (svn revision 238763) >>> and got after day of work: >> [...] >>> It seems, it continued to add files to some archive recursively... Is it >>> a bug or maybe I just can't cook it properly? >> >> just to note: I just ran into the same thing with 9-STABLE > > This is a known change after 9.0-RELEASE, but out of curiosity, > how are you invoking make? I know how things in general need to be > fixed but I need to figure out which variable you're passing in > incorrectly. Another good reference to note: http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025326.html . You're not the first people to stumble on this, so I'm filing a PR to help fix it. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make release recursion
On Fri, Jul 27, 2012 at 7:26 AM, Oliver Brandmueller wrote: > Hi, > > On Fri, Jul 27, 2012 at 09:35:13AM +0400, Alexander Pyhalov wrote: >> Hello. >> I've tried to do "make cdrom" on recent 10-current (svn revision 238763) >> and got after day of work: > [...] >> It seems, it continued to add files to some archive recursively... Is it >> a bug or maybe I just can't cook it properly? > > just to note: I just ran into the same thing with 9-STABLE This is a known change after 9.0-RELEASE, but out of curiosity, how are you invoking make? I know how things in general need to be fixed but I need to figure out which variable you're passing in incorrectly. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make release recursion
Hi, On Fri, Jul 27, 2012 at 09:35:13AM +0400, Alexander Pyhalov wrote: > Hello. > I've tried to do "make cdrom" on recent 10-current (svn revision 238763) > and got after day of work: [...] > It seems, it continued to add files to some archive recursively... Is it > a bug or maybe I just can't cook it properly? just to note: I just ran into the same thing with 9-STABLE - Oliver -- | Oliver Brandmueller http://sysadm.in/ o...@sysadm.in | |Ich bin das Internet. Sowahr ich Gott helfe. | ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (void)foo or __unused foo ?
On Fri, Jul 27, 2012 at 11:20:48AM +, Poul-Henning Kamp wrote:
> In message <20120727093824.gb56...@onelab2.iet.unipi.it>, Luigi Rizzo writes:
>
> >The alternative way to avoid an 'unused' warning from the compiler
> >is an empty statement
> >
> > (void)foo;
>
> The thing I don't like about this form, is that it doesn't communicate
> your intention, only your action.
>
> Somewhere down my TODO list I have an item to propose instead:
>
> typedef void unused_t;
>
> int main(int argc, char **argv)
> {
>
> (unused_t)argc;
> (unused_t)argv;
> return (0);
> }
i certainly like this better, my only concern is that some other
platform might come with an incompatible usage of the name 'unused_t'
same as it happened for __unused, and we are back with the problem.
A comment might be used to explain the intention in even more detail:
(void)foo; /* unused on XyBSD and Babbage-OS */
cheers
luigi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (void)foo or __unused foo ?
In message <20120727093824.gb56...@onelab2.iet.unipi.it>, Luigi Rizzo writes:
>The alternative way to avoid an 'unused' warning from the compiler
>is an empty statement
>
> (void)foo;
The thing I don't like about this form, is that it doesn't communicate
your intention, only your action.
Somewhere down my TODO list I have an item to propose instead:
typedef void unused_t;
int main(int argc, char **argv)
{
(unused_t)argc;
(unused_t)argv;
return (0);
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
about netmap num_rx_desc.
in netmap_kern.h
struct netmap_adapter {
..
u_int num_rx_desc;
//u_int buff_size; // XXX deprecate, use NETMAP_BUF_SIZE
but in netmap.c
int
netmap_attach(struct netmap_adapter *na, int num_queues)
{
na->num_rx_rings = num_queues;
ixgbe_netmap.h
static void
ixgbe_netmap_attach(struct adapter *adapter)
{
...
netmap_attach(&na, adapter->num_queues);
}
why not use the netmap_buf_size as na->num_rx_rings;
then will be have a larger buffer___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (void)foo or __unused foo ?
On 2012-07-27 11:38, Luigi Rizzo wrote: > In writing cross platform code I often have to deal with function > arguments or variables that are not used on certain platforms. > In FreeBSD:sys/cdefs.h we have > > #define __unused__attribute__((__unused__)) > > and in the kernel we tend to annotate with "__unused" such arguments > > int f(type foo __unused) > > However on linux __unused is not a standard macro, and is often > used as a variable or field name in standard headers, so introducing > our __unused macro breaks compilation there. Hm, Linux seems to use __unused for padding in structs, and as the name (!!) of unused parameters in prototypes. :( It uses the following for unused attributes: #define __maybe_unused __attribute__((unused)) #define __always_unused __attribute__((unused)) The former seems to be used much more throughout the Linux sources, I count 243 instances of it in my copy, as opposed to just 9 of the latter. I don't really understand the rationale (if any) for two different defines, though. > The alternative way to avoid an 'unused' warning from the compiler > is an empty statement > > (void)foo; > > that the compiler hopefully optimizes away. > > Any disadvantage or objection to selectively use this form > in our kernel code for parts that need to work on multiple > platforms ? Better to just define a UNUSED_ARG() macro for this, that does the cast. This will save you having to go over every file again, should you ever encounter a compiler that complains about useless casts to void... Then again, whatever macro name we come up with, might also clash with Linux. I'm afraid there is no good portable solution, except possibly undefining __unused just before including Linux headers, then re-defining it, but that is rather ugly. Otherwise, either Linux renames all their __unused instances, or we rename all of them. Alternatively, we can introduce an __unused2 macro, just as ugly as the __dead2 and __pure2 macros. Then replace __unused with __unused2 in the files that you intend to port to Linux. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (void)foo or __unused foo ?
Hi, On Fri, 27 Jul 2012 11:38:24 +0200 Luigi Rizzo wrote: > In writing cross platform code I often have to deal with function > arguments or variables that are not used on certain platforms. > In FreeBSD:sys/cdefs.h we have > if I understand you right here, it is you own code that has to run on different platforms. I can only tell what we are doing since a long long time. We have one file which handles all these things in one central location. This makes all other files independent of the platform but this one file might needs some work when a new platform comes in or things change on one platform. > Any disadvantage or objection to selectively use this form > in our kernel code for parts that need to work on multiple > platforms ? This concept also works inside a kernel, driver or in the world. The concept should then be limited to the module. Erich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Change default for periodic/weekly/400.status-pkg ?
Miroslav Lachman wrote: > I think it should be user configurable in /etc/periodic.conf if > somebody want to use INDEX or not. It already is user configurable. My point is to change the default, because the current default is useless. It should also be noted that change is "safe", because the output of the weekly cron script does not change at all if everything is alright. Only if some ports lost their origin, this fact is noted in the output. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered." -- Guido van Rossum ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
(void)foo or __unused foo ?
In writing cross platform code I often have to deal with function arguments or variables that are not used on certain platforms. In FreeBSD:sys/cdefs.h we have #define __unused__attribute__((__unused__)) and in the kernel we tend to annotate with "__unused" such arguments int f(type foo __unused) However on linux __unused is not a standard macro, and is often used as a variable or field name in standard headers, so introducing our __unused macro breaks compilation there. The alternative way to avoid an 'unused' warning from the compiler is an empty statement (void)foo; that the compiler hopefully optimizes away. Any disadvantage or objection to selectively use this form in our kernel code for parts that need to work on multiple platforms ? cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Change default for periodic/weekly/400.status-pkg ?
Oliver Fromme wrote: Hi, Currently, the periodic/weekly/400.status-pkg script uses the ports' INDEX file if it exists. On my machines, the INDEX file exists, and the periodic script produces output like this: $ /etc/periodic/weekly/400.status-pkg Check for out of date packages: $ That is, apparently everything is up to date, so I don't have to do anything. But this is wrong. When I change it to use /nonexistent in place of the INDEX file, I get this output: $ /etc/periodic/weekly/400.status-pkg Check for out of date packages: netpbm-manpages-10.35.85 was orphaned: LOCAL/netpbm-manpages pkg-config-0.25_1 was orphaned: devel/pkg-config $ A-ha! The first line is to be expected (netpbm-manpages is a "fake" port that I maintain locally), but the second line about pkg-config is much more important. Now this makes me look at ports/UPDATING, revealing that pkg-config was replaced by pkgconf. Therefore I propose to change the default for the periodic script to use /nonexistent. It does not change the output that usually appears, it only produces _additional_ output for installed packages whose origin disappeared. This is valuable information, I think. Also, the INDEX file could be outdated, which might lead to wrong results, so using the INDEX file by default is probably not a good idea anyway. On the other hand - we are using daily `portsnap -I update` so we have updated INDEX on all our machines, but outdated ports tree. (freezed in some point in time, so we can have same versions installed on all servers in a group) I think it should be user configurable in /etc/periodic.conf if somebody want to use INDEX or not. Or the hack with /nonexistent should be mentioned in a comment in /etc/defaults/periodic.conf and in a manpage. Miroslav Lachman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Change default for periodic/weekly/400.status-pkg ?
Hi, Currently, the periodic/weekly/400.status-pkg script uses the ports' INDEX file if it exists. On my machines, the INDEX file exists, and the periodic script produces output like this: $ /etc/periodic/weekly/400.status-pkg Check for out of date packages: $ That is, apparently everything is up to date, so I don't have to do anything. But this is wrong. When I change it to use /nonexistent in place of the INDEX file, I get this output: $ /etc/periodic/weekly/400.status-pkg Check for out of date packages: netpbm-manpages-10.35.85 was orphaned: LOCAL/netpbm-manpages pkg-config-0.25_1 was orphaned: devel/pkg-config $ A-ha! The first line is to be expected (netpbm-manpages is a "fake" port that I maintain locally), but the second line about pkg-config is much more important. Now this makes me look at ports/UPDATING, revealing that pkg-config was replaced by pkgconf. Therefore I propose to change the default for the periodic script to use /nonexistent. It does not change the output that usually appears, it only produces _additional_ output for installed packages whose origin disappeared. This is valuable information, I think. Also, the INDEX file could be outdated, which might lead to wrong results, so using the INDEX file by default is probably not a good idea anyway. Last but not least: Contrary to what the pkg_version(1) manpage suggests, the periodic script actually finishes slightly faster when no INDEX file is used. There doesn't seem to be any reason why the real INDEX file should be used. What do you think? Best regards Oliver PS: Specifying /nonexistent is different from /dev/null. The latter makes pkg_version assume that it is an empty INDEX file, causing different behaviour (not useful) than a non-existing file. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is the only current language making COBOL look good." -- Bertrand Meyer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
