Re: [PATCH] Add HISTORY to strlen(3) and strstr(3) man pages
On Mon, Dec 6, 2010 at 9:33 AM, Lars Engels wrote: > On Sat, Dec 04, 2010 at 06:00:02PM +0200, Marin Atanasov Nikolov wrote: >> On Sat, Dec 4, 2010 at 1:38 PM, Matthias Andree >> wrote: >> > Am 04.12.2010 12:33, schrieb Marin Atanasov Nikolov: >> >> Hello, >> >> >> >> Could someone review the attached patches and possibly commit them? >> >> >> >> The patches add HISTORY for the strstr(), strnstr(), strlen() and >> >> strnlen() functions. >> >> >> >> Thanks, >> >> Marin >> > >> > I find it hard to believe the versions especially for strstr and strlen. >> >> You are so right about that :) >> >> That must be one those copy-paste mistakes :) >> >> I've attached the new patches. >> >> Regards, >> Marin > Hi, > It should be "FreeBSD 8.0" not "8.0" like in the other manpages. > .Fx is a FreeBSD macro, so ".Fx 8.0 ." is "FreeBSD 8.0". Or I have misunderstood something? Regards, Marin -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/ ___ 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 HISTORY to strlen(3) and strstr(3) man pages
On Sat, Dec 04, 2010 at 06:00:02PM +0200, Marin Atanasov Nikolov wrote: > On Sat, Dec 4, 2010 at 1:38 PM, Matthias Andree > wrote: > > Am 04.12.2010 12:33, schrieb Marin Atanasov Nikolov: > >> Hello, > >> > >> Could someone review the attached patches and possibly commit them? > >> > >> The patches add HISTORY for the strstr(), strnstr(), strlen() and > >> strnlen() functions. > >> > >> Thanks, > >> Marin > > > > I find it hard to believe the versions especially for strstr and strlen. > > You are so right about that :) > > That must be one those copy-paste mistakes :) > > I've attached the new patches. > > Regards, > Marin It should be "FreeBSD 8.0" not "8.0" like in the other manpages. pgpIYxyExyNRp.pgp Description: PGP signature
Re: [PATCH] Add HISTORY to strlen(3) and strstr(3) man pages
On Mon, Dec 06, 2010 at 10:31:28AM +0200, Marin Atanasov Nikolov wrote: > On Mon, Dec 6, 2010 at 9:33 AM, Lars Engels wrote: > > On Sat, Dec 04, 2010 at 06:00:02PM +0200, Marin Atanasov Nikolov wrote: > >> On Sat, Dec 4, 2010 at 1:38 PM, Matthias Andree > >> wrote: > >> > Am 04.12.2010 12:33, schrieb Marin Atanasov Nikolov: > >> >> Hello, > >> >> > >> >> Could someone review the attached patches and possibly commit them? > >> >> > >> >> The patches add HISTORY for the strstr(), strnstr(), strlen() and > >> >> strnlen() functions. > >> >> > >> >> Thanks, > >> >> Marin > >> > > >> > I find it hard to believe the versions especially for strstr and strlen. > >> > >> You are so right about that :) > >> > >> That must be one those copy-paste mistakes :) > >> > >> I've attached the new patches. > >> > >> Regards, > >> Marin > > > > Hi, > > > It should be "FreeBSD 8.0" not "8.0" like in the other manpages. > > > > .Fx is a FreeBSD macro, so ".Fx 8.0 ." is "FreeBSD 8.0". > > Or I have misunderstood something? > > Regards, > Marin Uh, yes. Sorry. :) pgpS2dtHPX8cm.pgp Description: PGP signature
Re: coretemp(4)/amdtemp(4) and sysctl nodes
On Friday, December 03, 2010 1:05:02 pm m...@freebsd.org wrote: > There are very few uses in FreeBSD mainline code of > sysctl_remove_oid(), and I was looking at potentially removing them. > However, the use in coretemp/amdtemp has me slightly stumped. > > Each device provides a device_get_sysctl_ctx sysctl_ctx that is > automatically cleaned up when the device goes away. Yet the sysctl > nodes for both amdtemp and coretemp use the context of other devices, > rather than their own. I can't quite figure out why, though the two > are slightly different enough that they may have different reasons. > > For coretmp(4) I don't see how the parent device can be removed first, > since we are a child device. So from my understanding it makes no > sense to have an explicit sysctl_remove_oid() and attach in the > parent's sysctl_ctx. Well, you would want 'kldunload coretemp.ko' to remove the sysctl node even though the parent device is still around. I suspect the same case is true for amdtemp. Probably these drivers should use a separate sysctl context. I'm not sure how the sysctl code handles removing a node that has an active context though. -- John Baldwin ___ 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: small dtrace patch for review
On Friday, December 03, 2010 11:57:42 am Andriy Gapon wrote: > > The patch is not about DTrace functionality, but about infrastructure use in > one > particular place. > http://people.freebsd.org/~avg/dtrace_gethrtime_init.diff > I believe that sched_pin() is need there to make sure that "host"/base CPU > stays > the same for all calls to smp_rendezvous_cpus(). > The pc_cpumask should just be a cosmetic change. Looks good to me. -- John Baldwin ___ 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"
Review needed. Re: kern/152822: [patch] DTrace: syscall provider for compat/freebsd32
Hi, Could someone review the patch in the PR? It adds DTrace syscall32 provider that allows syscall probing for 32-bit binaries running under emulation. http://www.freebsd.org/cgi/query-pr.cgi?pr=152822 Thanks, --Artem -- Forwarded message -- From: Artem Belevich Date: Fri, Dec 3, 2010 at 9:30 PM Subject: Fwd: kern/152822: [patch] DTrace: syscall provider for compat/freebsd32 To: Andriy Gapon Andriy, I've submitted a PR with the partial patch included. freebsd32_systrace_args.c will have to be regenerated with "make sysent" If you think it may be useful, feel free to commit it. --Artem -- Forwarded message -- From: Date: Fri, Dec 3, 2010 at 9:20 PM Subject: Re: kern/152822: [patch] DTrace: syscall provider for compat/freebsd32 To: Artem Belevich Thank you very much for your problem report. It has the internal identification `kern/152822'. The individual assigned to look at your report is: freebsd-bugs. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=152822 >Category: kern >Responsible: freebsd-bugs >Synopsis: [patch] DTrace: syscall provider for compat/freebsd32 >Arrival-Date: Sat Dec 04 05:20:10 UTC 2010 ___ 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"
