which Wifi cards can be used for a WAP?
I'm looking at the impressive list of wireless network cards supported by FreeBSD here: http://www.freebsd.org/releases/5.3R/hardware-i386.html#WLAN But, I have the specific interest of building an 802.11g WAP. I seem to recall lore that not all Wifi cards could be used this way (something about needing to be able to run in ad-hoc mode, or some such.) Is my memory faulty, or can any old 802.11g Wifi card be pressed into service? I'm specifically looking into various PCI-based cards, if that affects anyone's advice... (If someone can recomment a better forum for the question; I'll accept advice on that matter, too. :) Of course, any specific advice about good antenna, good driver/throughput, etc, would also be accepted gleefully... -- Brian Reichert <[EMAIL PROTECTED]> 55 Crystal Ave. #286Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: enable acpi
On 03/31/05 20:51 John Baldwin said the following: The problem is that the taskqueue_swi in 4.x doesn't have a thread context that can be slept on via tsleep(). The fix would be to create a kthread in which to run the ACPI tasks. 4.x already has one such kthread for the taskqueue_thread taskqueue that you could use as a reference if you wish to do this yourself. thanx for the pointer, john. with your explanation, the fix was simple. since applying this, it's not paniced in over 24 hours of continuous running. patch attached. i'll also raise a PR for this. -- Regards, /\_/\ "All dogs go to heaven." [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=+ --- sys/dev/acpica/Osd/OsdSchedule.c.orig Thu Mar 31 00:35:42 2005 +++ sys/dev/acpica/Osd/OsdSchedule.cFri Apr 1 13:55:00 2005 @@ -192,7 +192,7 @@ TASK_INIT(&at->at_task, pri, AcpiOsExecuteQueue, at); #if __FreeBSD_version < 50 -taskqueue_enqueue(taskqueue_swi, (struct task *)at); +taskqueue_enqueue(taskqueue_thread, (struct task *)at); #else taskqueue_enqueue(taskqueue_acpi, (struct task *)at); #endif ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4BSD Scheduler Problem on 5.3
I'm not sure if it's before or after your changes, Poul-Henning. If there is a newer -RELEASE I can upgrade too, I will do that. I don't really want to upgrade to -STABLE, but I will also do that to relieve the issue if necessary. Just give me a recommendation on to either update RELEASE beyond -p1 or to go ahead and update to -STABLE. I appreciate the help all of you have been. Thanks much. On Fri, Apr 01, 2005 at 08:52:38PM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, John Baldwin writes: > > >> I think we have a race in -STABLE relating to tty wakeups and > >> open/close/device teardown. I've seen a panic relating to sio during a > >> tty close on RELENG_5 about 5-6 months ago, but was unable to get a dump. > >> Scott has since fixed dumps with twe, but I've not yet been able to get > >> the bug to recur. I'll give it another try. > > > >Sounds very plausible. Does Poul-Henning have any ideas? > > Is this before or after my tty changes ? > > There is a general nastyness about ttys/sessions/exit which I have > never really felt comfortable about. My hope is that I have solved > it by refcounting the tty structure. > > So if this is before my changes: "Yeah, known (but rare) issue)" > > If after my changes: "D**N!" > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- William Michael Grim Student, Southern Illinois University at Edwardsville Unix Network Administrator, SIUE, Computer Science dept. Phone: (217) 341-6552 Email: [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4BSD Scheduler Problem on 5.3
On Fri, 1 Apr 2005, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, John Baldwin writes: > > >> I think we have a race in -STABLE relating to tty wakeups and > >> open/close/device teardown. I've seen a panic relating to sio during a > >> tty close on RELENG_5 about 5-6 months ago, but was unable to get a dump. > >> Scott has since fixed dumps with twe, but I've not yet been able to get > >> the bug to recur. I'll give it another try. > > > >Sounds very plausible. Does Poul-Henning have any ideas? > > Is this before or after my tty changes ? > > There is a general nastyness about ttys/sessions/exit which I have never > really felt comfortable about. My hope is that I have solved it by > refcounting the tty structure. > > So if this is before my changes: "Yeah, known (but rare) issue)" > > If after my changes: "D**N!" The instance of the panic I saw was in RELENG_5 in January when using a serial console. Here's a copy of the e-mail I sent to stable@ when it occurred. It's a little weak on the debugging side because I couldn't get a dump and didn't have a kernel with symbols easily on hand, but my reading was that there was a race relating to open/close and device events. Robert N M Watson Date: Sun, 23 Jan 2005 16:51:14 + (GMT) From: Robert Watson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: NULL pointer deref in sioopen() suggests a close/open race on sio device? Ran into the following panic on a 5-STABLE box this morning, which occurred after hitting Ctrl-D to close a login session on a serial console (ttyd0 at 9600 bps): login: Jan 23 10:43:27 fledge login: 2 LOGIN FAILURES ON ttyd0 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1c fault code = supervisor write, page not present instruction pointer = 0x8:0xc051537b stack pointer = 0x10:0xe7345988 frame pointer = 0x10:0xe7345994 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 45092 (getty) [thread pid 45092 tid 100201 ] Stopped at knote+0x27: cmpxchgl%ecx,0x1c(%edx) db> show pcpu cpuid= 0 curthread= 0xc290d190: pid 45092 "getty" curpcb = 0xe7345da0 fpcurthread = 0xc290d190: pid 45092 "getty" idlethread = 0xc22644b0: pid 11 "idle" APIC ID = 0 currentldt = 0x30 db> trace Tracing pid 45092 tid 100201 td 0xc290d190 knote(c264e098,0,0,c290d190,e73459c4) at knote+0x27 ttwwakeup(c264e000) at ttwwakeup+0xc8 comstart(c264e000) at comstart+0x385 comparam(c264e000,c264e0a4,c264e000,3,0) at comparam+0x253 sioopen(c079f060,3,2000,c290d190,c078e6a0) at sioopen+0x1df spec_open(e7345a84,e7345b40,c058d585,e7345a84,180) at spec_open+0x2b6 spec_vnoperate(e7345a84) at spec_vnoperate+0x13 vn_open_cred(e7345be4,e7345ce4,c08,c2261d80,0) at vn_open_cred+0x419 vn_open(e7345be4,e7345ce4,c08,0,c4289b58) at vn_open+0x1e kern_open(c290d190,804f8e0,0,3,bfbfee18) at kern_open+0xe3 open(c290d190,e7345d14,3,0,292) at open+0x18 syscall(2f,2f,2f,804f8e0,0) at syscall+0x27b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip = 0x280d155b, esp = 0xbfbfedec, ebp = 0xbfbfee18 --- The ps list is a bit boring, but the primary interesting thing is that it looks like the close was going on in one thread just about when the sio swi was scheduled to run also: db> ps pid proc uarea uid ppid pgrp flag stat wmesgwchan cmd 45092 c6762388 e73870000 1 1 0004000 [CPU 0] getty ... 132 c235954c e4fbf0000 0 0 20c [RUNQ] swi5: clock sio I didn't have a kernel with debugging symbols on-hand, but the above address in knote() is a cmpxchg early in the function, which means it's likely the conditional call to mtx_lock() hitting a NULL mutex pointer for kl_lock. This in turn suggests that something has called ttyrel/tty_close on the TTY in a race with the open, or otherwise NULL'd that pointer via knlist_destroy(). Anyone have any pointers on this one? The TTY code is not my forte... Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4BSD Scheduler Problem on 5.3
In message <[EMAIL PROTECTED]>, John Baldwin writes: >> I think we have a race in -STABLE relating to tty wakeups and >> open/close/device teardown. I've seen a panic relating to sio during a >> tty close on RELENG_5 about 5-6 months ago, but was unable to get a dump. >> Scott has since fixed dumps with twe, but I've not yet been able to get >> the bug to recur. I'll give it another try. > >Sounds very plausible. Does Poul-Henning have any ideas? Is this before or after my tty changes ? There is a general nastyness about ttys/sessions/exit which I have never really felt comfortable about. My hope is that I have solved it by refcounting the tty structure. So if this is before my changes: "Yeah, known (but rare) issue)" If after my changes: "D**N!" -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4BSD Scheduler Problem on 5.3
On Thursday 31 March 2005 08:03 pm, Robert Watson wrote: > On Thu, 31 Mar 2005, John Baldwin wrote: > > On Thursday 31 March 2005 03:38 pm, William Michael Grim wrote: > > > Hello. > > > > > > I keep having kernel panics every couple weeks on my system. It occurs > > > in the sched_switch() function. There are several other statements in > > > the backtrace involving "??"; what are those? > > > > > > I have attached the dump output and system info to this email. Any > > > feedback would be helpful. > > > > > > Thanks so much for your help. > > > > The real trace ends with Xint0x80_syscall(). The rest after that is > > garbage memory. Your real problem is in exit1() or ttywakeup(). Since > > ttywakeup() doesn't call exit1() (AFAIK), the exit1() frame is probably > > bogus (gdb doesn't grok trapframes maybe?) and the real bug is a NULL > > pointer deref in ttywakeup(). Perhaps it's a bug in the ptc driver? > > (ptcopen is in the trace). What is the ptc driver anyway? > > I think we have a race in -STABLE relating to tty wakeups and > open/close/device teardown. I've seen a panic relating to sio during a > tty close on RELENG_5 about 5-6 months ago, but was unable to get a dump. > Scott has since fixed dumps with twe, but I've not yet been able to get > the bug to recur. I'll give it another try. Sounds very plausible. Does Poul-Henning have any ideas? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fwd: 5-STABLE kernel build with icc broken
Here is the core of the FPU setup and restoration code for the kernel bcopy in DragonFly, from i386/bcopy.s. DragonFly uses the TD_SAVEFPU-is-a-pointer method that was outlined in the original comment in the FreeBSD code. I further enhance the algorithm to guarentee that the FPU is in a sane state (does not require any further initialization other then a clts) if userland has NOT used it. However, there are definitely some race cases that must be considered (see the comments). The on-fault handling in DragonFly is stackable (which further simplifies the whole mess of on-fault vs non-on-fault copying code) and the DFly bcopy just sets up the frame for it whether or not the onfault handling is actually needed. This could be further optimized, but I had already spent at least a month on it and had to move on to other things. In particular, the setting of CR0_TS and the restoration of TD_SAVEFPU could be moved to the syscall-return code, so multiple in-kernel bcopy operations could be issued without any further FPU setup or teardown. -Matt /* * RACES/ALGORITHM: * * If gd_npxthread is not NULL we must save the application's * current FP state to the current save area and then NULL * out gd_npxthread to interlock against new interruptions * changing the FP state further. * * If gd_npxthread is NULL the FP unit is in a known 'safe' * state and may be used once the new save area is installed. * * race(1): If an interrupt occurs just prior to calling fxsave * all that happens is that fxsave gets a npxdna trap, restores * the app's environment, and immediately traps, restores, * and saves it again. * * race(2): No interrupt can safely occur after we NULL-out * npxthread until we fninit, because the kernel assumes that * the FP unit is in a safe state when npxthread is NULL. It's * more convenient to use a cli sequence here (it is not * considered to be in the critical path), but a critical * section would also work. * * race(3): The FP unit is in a known state (because npxthread * was either previously NULL or we saved and init'd and made * it NULL). This is true even if we are preempted and the * preempting thread uses the FP unit, because it will be * fninit's again on return. ANY STATE WE SAVE TO THE FPU MAY * BE DESTROYED BY PREEMPTION WHILE NPXTHREAD IS NULL! However, * an interrupt occuring inbetween clts and the setting of * gd_npxthread may set the TS bit again and cause the next * npxdna() to panic when it sees a non-NULL gd_npxthread. * * We can safely set TD_SAVEFPU to point to a new uninitialized * save area and then set GD_NPXTHREAD to non-NULL. If an * interrupt occurs after we set GD_NPXTHREAD, all that happens * is that the safe FP state gets saved and restored. We do not * need to fninit again. * * We can safely clts after setting up the new save-area, before * installing gd_npxthread, even if we get preempted just after * calling clts. This is because the FP unit will be in a safe * state while gd_npxthread is NULL. Setting gd_npxthread will * simply lock-in that safe-state. Calling clts saves * unnecessary trap overhead since we are about to use the FP * unit anyway and don't need to 'restore' any state prior to * that first use. */ #define MMX_SAVE_BLOCK(missfunc)\ cmpl$2048,%ecx ;\ jb missfunc ; \ movlMYCPU,%eax ;/* EAX = MYCPU */ \ btsl$1,GD_FPU_LOCK(%eax) ; \ jc missfunc ; \ pushl %ebx ; \ pushl %ecx ; \ movlGD_CURTHREAD(%eax),%edx ; /* EDX = CURTHREAD */ \ movlTD_SAVEFPU(%edx),%ebx ; /* save app save area */\ addl$TDPRI_CRIT,TD_PRI(%edx) ; \ cmpl$0,GD_NPXTHREAD(%eax) ; \ je 100f ; \ fxsave 0(%ebx) ; /* race(1) */ \
Re: Fwd: 5-STABLE kernel build with icc broken
:>The use of the XMM registers is a cpu optimization. Modern CPUs, :>especially AMD Athlon and Opterons, are more efficient with 128 bit :>moves then with 64 bit moves. I experimented with all sorts of :>configurations, including the use of special data caching instructions, :>but they had so many special cases and degenerate conditions that :>I found that simply using straight XMM instructions, reading as big :>a glob as possible, then writing the glob, was by far the best solution. : :Are you sure about that? The amd64 optimization manual says (essentially) :that big globs are bad, and my benchmarks confirm this. The best glob size :is 128 bits according to my benchmarks. This can be obtained using 2 :... : :Unfortunately (since I want to avoid using both MMX and XMM), I haven't :managed to make copying through 64-integer registers work as well. :Copying 128 bits at a time using 2 pairs of movq's through integer :registers gives only 7.9GB/sec. movq through MMX is never that slow. :However, movdqu through xmm is even slower (7.4GB/sec). : :The fully cached case is too unrepresentative of normal use, and normal :(partially cached) use is hard to bencmark, so I normally benchmark :the fully uncached case. For that, movnt* is best for benchmarks but :not for general use, and it hardly matters which registers are used. Yah, I'm pretty sure. I tested the fully cached (L1), partially cached (L2), and the fully uncached cases. I don't have a logic analyzer but what I think is happening is that the cpu's write buffer is messing around with the reads and causing extra RAS cycles to occur. I also tested using various combinations of movdqa, movntdq, and prefetcha. carefully arranged non-temporal and/or prefetch instructions were much faster for the uncached case, but much, MUCH slower for the partially cached (L2) or fully (L1) cached case, making them unsuitable for a generic copy. I am rather miffed that AMD screwed up the non-temporal instructions so badly. I also think there might be some odd instruction pipeline effects that skew the results when only one or two instructions are between the load into an %xmm register and the store from the same register. I tried using 2, 4, and 8 XMM registers. 8 XMM registers seemed to work the best. Of course, I primarily tested on an Athlon 64 3200+, so YMMV. (One of the first Athlon 64's, so it has a 1MB L2 cache). :>The key for fast block copying is to not issue any memory writes other :>then those related directly to the data being copied. This avoids :>unnecessary RAS cycles which would otherwise kill copying performance. :>In tests I found that copying multi-page blocks in a single loop was :>far more efficient then copying data page-by-page precisely because :>page-by-page copying was too complex to be able to avoid extranious :>writes to memory unrelated to the target buffer inbetween each page copy. : :By page-by-page, do you mean prefetch a page at a time into the L1 :cache? No, I meant that copying taking, e.g. a vm_page_t array and doing page-by-page mappings copying in 4K chunks seems to be a lot slower then doing a linear mapping of the entire vm_page_t array and doing one big copy. Literally the same code, just rearranged a bit. Just writing to the stack in between each page was enough to throw it off. :I've noticed strange loss (apparently) from extraneous reads or writes :more for benchmarks that do just (very large) writes. An at least old :Celerons and AthlonXPs, the writes go straight to the L1/L2 caches :(unless you use movntq on AthlonXP's). The caches are flushed to main :memory some time later, apparently not very well since some pages take :more than twice as long to write as others (as seen by the writer :filling the caches), and the slow case happens enough to affect the :average write speed by up to 50%. This problem can be reduced by :putting memory bank bits in the page colors. This is hard to get right :even for the simple unrepresentative case of large writes. : :Bruce I've seen the same effects and come to the same conclusion. The copy code I eventually settled on was this (taken from my i386/bcopy.s). It isn't as fast as using movntdq for the fully uncached case, but it seems to perform in the system the best because the data tends to be accessed and in the cache by someone in real life (e.g. source data tends to be in the cache even if the device driver doesn't touch the target data). I wish AMD had made movntdq work the same as movdqa for the case where the data was already in the cache, then movntdq would have been the clear winner. The prefetchnta I have commented out seemed to improve performance, but it requires 3dNOW and I didn't want to NOT have an MMX copy mode for cpu's with MMX but without 3dNOW.
Re: organization
mohamed aslan wrote: hi guys it's my first post here, BTW i was a linux hacker and linux kernel mailing list member for 3 years. I am driver developer, and I work with both Linux and FreeBSD. It is usual for me to changed OS I am working with a several times a day. What can I say, both source trees have some organization problems. Personally I prefer BSD one and more dislike Linux one. IMHO this is matter of taste. By the way is this your first feeling or you have some experience with BSD hacking? (e.q. try to start programming using other language or other environment, the first feeling would be the same) rik and i've a comment here , i think the freebsd kernel source files aren't well organized as linux ones. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fwd: 5-STABLE kernel build with icc broken
On Thu, 31 Mar 2005, Matthew Dillon wrote: I didn't mean to get into the kernel's use of the FPU, but... All I really did was implement a comment that DG had made many years ago in the PCB structure about making the FPU save area a pointer rather then hardwiring it into the PCB. ISTR writing something like that. dg committed most of my early work since I didn't have commit access at the time. ... The use of the XMM registers is a cpu optimization. Modern CPUs, especially AMD Athlon and Opterons, are more efficient with 128 bit moves then with 64 bit moves. I experimented with all sorts of configurations, including the use of special data caching instructions, but they had so many special cases and degenerate conditions that I found that simply using straight XMM instructions, reading as big a glob as possible, then writing the glob, was by far the best solution. Are you sure about that? The amd64 optimization manual says (essentially) that big globs are bad, and my benchmarks confirm this. The best glob size is 128 bits according to my benchmarks. This can be obtained using 2 64-bit reads of 64-bit registers followed by 2 64-bit writes of these registers, or by read-write of a single 128-bit register. The 64-bit registers can be either MMX or integer registers on 64-bit systems, but the 128-registers must be XMM on all systems. I get identical speeds of 12.9GB/sec (+-0.1GB/sec) on a fairly old and slow Athlon64 system for copying 16K (fully cached) through MMX and XMM 128 bits at a time using the following instructions: # MMX: # XMM movq(%0),%mm0 movdqa (%0),%xmm0 movq8(%0),%mm1 movdqa %xmm0,(%1) movq%mm0,(%1) ... # unroll same amount movq%mm1,8(%1) ... # unroll to copy 64 bytes per iteration Unfortunately (since I want to avoid using both MMX and XMM), I haven't managed to make copying through 64-integer registers work as well. Copying 128 bits at a time using 2 pairs of movq's through integer registers gives only 7.9GB/sec. movq through MMX is never that slow. However, movdqu through xmm is even slower (7.4GB/sec). The fully cached case is too unrepresentative of normal use, and normal (partially cached) use is hard to bencmark, so I normally benchmark the fully uncached case. For that, movnt* is best for benchmarks but not for general use, and it hardly matters which registers are used. The key for fast block copying is to not issue any memory writes other then those related directly to the data being copied. This avoids unnecessary RAS cycles which would otherwise kill copying performance. In tests I found that copying multi-page blocks in a single loop was far more efficient then copying data page-by-page precisely because page-by-page copying was too complex to be able to avoid extranious writes to memory unrelated to the target buffer inbetween each page copy. By page-by-page, do you mean prefetch a page at a time into the L1 cache? I've noticed strange loss (apparently) from extraneous reads or writes more for benchmarks that do just (very large) writes. An at least old Celerons and AthlonXPs, the writes go straight to the L1/L2 caches (unless you use movntq on AthlonXP's). The caches are flushed to main memory some time later, apparently not very well since some pages take more than twice as long to write as others (as seen by the writer filling the caches), and the slow case happens enough to affect the average write speed by up to 50%. This problem can be reduced by putting memory bank bits in the page colors. This is hard to get right even for the simple unrepresentative case of large writes. Bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Making gcc "-Wformat" more verbose
On Wed, Mar 30, 2005 at 08:12:08PM +0200, Marc Olzheim wrote: > Please have a look at it and tell me whether this could be useful for > FreeBSD or whether that's a bridge too far... > > The patch is at > http://www.stack.nl/~marcolz/FreeBSD/gcc-printf.patch.txt > > Besides that, you'll need to include the inttypes.h at > http://www.stack.nl/~marcolz/FreeBSD/inttypes.h instead of > /usr/include/inttypes.h > > If you want to compile the kernel with it, make sure to turn of > -Werror... (Or install into somewhere else then /usr/libexec and use > CFLAGS=-B to gcc to try it out. I modified it, so that you need to supply -Wformat-pre-promo in addition to -Wformat to get the extra output... Marc pgpZLx0o0CSBb.pgp Description: PGP signature
Re: subtracting days from localtime problem
I attached an example which shows the DST related changes
this year. I just couldn't resist writing something where
I get to use rare values such as 1112345678 and 1131131131
in a meaningful way. :-)
ALeine
___
WebMail FREE http://mail.austrosearch.net /*-
* Copyright (c) 2005 ALeine <[EMAIL PROTECTED]>
* All rights reserved.
*
* Imported into CVS repository at exactly 1112345678 seconds
* since the Epoch.
*
* $Id: dst_2005.c,v 1.1.1.1 2005/04/01 08:54:38 aleine Exp $
*
*/
#include
#include
void get_date_string_x_days_from_time(char *, size_t, int, time_t);
void get_date_string_x_days_before_time(char *, size_t, int, time_t);
int
main(void)
{
time_t now;
int last_day;
int day_offset;
chardate_string[32];
now = time(NULL);
/* Uncomment the following line to see what happens on 01-Apr-2005 */
/* now = 1112345678; */
/* Uncomment the following line to see what happens on 04-Nov-2005 */
/* now = 1131131131; */
fprintf(stderr, "Reference date and time: %s\n", ctime(&now));
last_day = 32;
for (day_offset = 1; day_offset < last_day; day_offset++) {
get_date_string_x_days_before_time(date_string,
sizeof(date_string),
day_offset,
now);
printf("%3d day%c before reference date: %s\n",
day_offset,
(day_offset > 1 ? 's' : ' '),
date_string);
}
return 0;
}
void
get_date_string_x_days_before_time(char *date_string,
size_t size,
int day_offset,
time_t time)
{
get_date_string_x_days_from_time(date_string, size, -day_offset, time);
}
void
get_date_string_x_days_from_time(char *date_string,
size_t size,
int day_offset,
time_t time)
{
struct tm *tm_p;
tm_p = localtime(&time);
tm_p->tm_mday += day_offset;
tm_p->tm_hour = tm_p->tm_min = tm_p->tm_sec = 0;
/* make mktime(3) figure out whether DST is in effect */
tm_p->tm_isdst = -1;
time = mktime(tm_p);
if (time == ((time_t) - 1))
printf("mktime(3) failed\n");
snprintf(date_string, size, "%d-%.2d-%.2d [DST: %d]",
tm_p->tm_year + 1900,
tm_p->tm_mon + 1,
tm_p->tm_mday,
tm_p->tm_isdst);
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: subtracting days from localtime problem
[EMAIL PROTECTED] wrote: > One more question, what will happen next time when > time goes back in October? > Does following line correct it as same as now? > > /* make mktime(3) figure out whether DST is in effect */ > t->tm_isdst = -1; Yes, it will work correctly. You can see what happens by setting now to 1131131131 (where you currently have now = time(NULL)). It's not an April Fools' Day joke, that just happens to be an appropriate time in November. :-) I also noticed a number of bugs in your code that you may want to fix: - memory leak: you are allocating memory with my_alloc(), but then you neither free(3) it nor keep track of it. You should remove my_alloc() and just create a buffer in main() and then pass it by reference to functions that need to modify its contents. - with my_alloc() you basically reinvented strdup(3), see man 3 strdup for details. You do not need strdup(3) for what you want to achieve, just pass the buffer from main() by reference and then use snprintf(3) to modify its contents. - snprintf(3) handles the size argument correctly, meaning that you should specify the full size of the string since at most size-1 characters are written with guaranteed NULL termination, see man 3 snprintf for details. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
