Keeping /etc/localtime up-to-date
Recent changes to /usr/share/zoneinfo have reminded me that my
regular updates to my FreeBSD machines via source update
/usr/share/zoneinfo, but /etc/localtime remains a copy of whatever
was in /usr/share/zoneinfo for the selected zone at the time
tzsetup(8) was last run -- and I certainly don't run tzsetup as
often as I update my sources (nor would I want to).
And while I (think I) recall that the equivalent of /etc/localtime
was implemented in some version of SunOS many years ago as a symlink,
I believe that approach could be problematic for FreeBSD, as it
could impose some unintended requirements on some of the start-up
scripts.
I believe that it would be appropriate to have a facility to update
/etc/localtime if the file to which it is supposed to correspond
in /usr/share/zoneinfo (now) differs.
Even if tzsetup is invoked with the -s flag and having the desired
zoneinfo file specified on the command-line, it goes into full-screen
mode and requests confirmation. Further, if the confirmation is
given, it unconditionally overwrites /etc/localtime.
It would (in principle) be possible to teach mergemaster(8) how to
do this (possibly by including a cookie in ~/.mergemasterrc or
/etc/mergemaster.rc to tell it what the reference zoneinfo pathname
is), but this type of approach seems sufficiently different from
(the bulk of?) what mergemaster does currently that I'm unconvinced
that this is reasonable, let alone ideal.
So it seems to me that requirements would be:
* The content of /etc/localtime must provide the appropriate
zoneinfo information, even when /usr/share/zoneinfo/* has been
modified (or shortly thereafter, in concert with make installworld).
* The content of /etc/localtime must be available when the only file
system mounted is the root file system (and prior to any attempt to
start any services (ref. {,/usr/local}/etc/rc.d)).
* The process must be amenable to automation; to that end, it must be
possible to perform it without requiring confirmation, and it
must be doable from a command-line.
* /etc/localtime should not be modified unless the content prior to
modification differs from the selected specification in
/usr/share/zoneinfo.
* The process should not add unnecessary complexity to existing tools
and procedures.
As a crude, brute-force hack, what I did (yesterday) was:
* Create a symlink (which I called /etc/tz) pointing to an
appropriate zoneinfo entry.
* Augment the commands I run on successful completion of make
installkernel (from src/UPDATING):
mergemaster -p
make installworld
mergemaster -i
make delete-old
by appending
cmp -s /etc/tz /etc/localtime || cp -p /etc/tz /etc/localtime
to the set.
While I make no claim as to elegance, I believe it meets the
requirements I listed.
Of course, another approach -- which is likely to be fairly popular
-- would be to run the machine on UTC, and let folks who want to
care about TZ stuff set their own personal TZ environment variables. :-}
Still, even that approach leads to the existence of /etc/localtime
as being somewhat of an attractive nuisance (in that if it exists,
it is likely to lead to a degree of mischief).
Thoughts?
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgpx4RXp8htO3.pgp
Description: PGP signature
Re: Prebind from OpenBSD
On Sat, 26 Mar 2011, Jesse Smith wrote: I'm interested in working on the Port prebind from OpenBSD project mentioned on the FreeBSD Ideas page. ( http://wiki.freebsd.org/IdeasPage#head-d28cdd95ca1755d5afe63d653cb4926d4bdc99de ) There isn't much to go on from the project description and I'm curious what FreeBSD devs are looking for specifically. For example, should the entire ldconfig program be ported from OpenBSD (it looks like it's close enough to FreeBSD's to make that suitable), or should just the prebind code be merged into FreeBSD's ldcnfig? Once the project is complete, who should the work be submitted to? Has anyone else worked on this and made any progress? Hi Jesse: I think the intent of the ideas list entry is more a research project than a direct-to-commit project: the question is whether prebinding of some sort would observably help performance for important FreeBSD applications or, for example, the boot process. If so, then certainly the OpenBSD prebinding code is a possible model -- Mac OS X also has prebinding, of course, and it's done quite differently (and probably less reusably from our perspective as they use Mach-O rather than ELF); however, there might be interesting ideas as well. I think therefore I'd structure a project along the following lines: first, you want to establish to what extent synchronous waiting on linkage at run-time is a significant problem. It could be that some combination of hwpmc and DTrace would be the right tools for this. I'd especially pay attention to boot time, since we know that quite a lot of executing takes place then as part of rc.d. I'd also investigate large applications like Firefox, Chrome, KDE, Gnome, etc. KDE already integrates prebinding tricks in its design, but I don't think the others do. Next, I'd dig a bit more into the areas where it's hurting performance -- can you add up all the time spent waiting and cut 10 seconds from boot, or 5 seconds from Firefox startup? Or is the best win going to be .2 seconds in Firefox? Does the OpenBSD optimisation actually address the problem we're experiencing? Perhaps perform some experiments with prebinding-like behaviour, working up to an implementation. It's worth remembering that prebinding comes with some baggage as well, of course. Perhaps less relevant in the world of 64-bit address spaces, but there are some design trade-offs in this department... Robert ___ 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
Unsigned wchar_t
Hello hackers@ I'm working on getting FreeBSD working with the ARM EABI. As part of this the Procedure Call Standard for the ARM Architecture (AAPCS) defines wchar_t as an unsigned int. Looking at sys/sys/_types.h rune_t, wchar_t and wint_t are of type __ct_rune_t which is an int. Furthermore as per the comment above the typedef rune_t must be signed to hold EOF of -1 and wchar_t must be the same type as rune_t. Because wchar_t is defined as an unsigned int would there be any issues with moving the typedef for __wchar_t to machine/_types.h and changing it from __ct_rune_t to int with the exception of the ARM EABI case? Along with this WCHAR_MIN and WCHAR_MAX are defined both in wchar.h and machine/_stdint.h. I would like to remove the copy from wchar.h and add an include to machine/_stdint.h. Would there be any problems with either of these or is there a better place to put the __wchar_t typedef and define WCHAR_MIN and WCHAR_MAX? Andrew ___ 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: GSoC
On Fri, 25 Mar 2011, Dudinskyi Olexandr wrote: My name is Dudinskyi Oleksandr. I am a student of National aviation university, Ukraine. I want to participate in GSoC 2011 with your organization. My project: Disk device error counters, iostat –e. I thing this project is very necessary in the FreeBSD system. Now I make a plan to develop this project. What you can say about the idea of my project? And what about the favor of this project? My mentor: Andriy Gapon. Hi Dudinskyi: It's a little hard to tell from your description exactly what it is you are proposing to do. Could you flesh out the idea some for us, so that we can give you feedback? What is the nature of the problem you want to solve? What software changes do you anticipate making? How will you test your changes? Robert___ 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: Prebind from OpenBSD
On Sun, Mar 27, 2011 at 08:54:18PM +0100, Robert Watson wrote: On Sat, 26 Mar 2011, Jesse Smith wrote: I'm interested in working on the Port prebind from OpenBSD project mentioned on the FreeBSD Ideas page. ( http://wiki.freebsd.org/IdeasPage#head-d28cdd95ca1755d5afe63d653cb4926d4bdc99de ) There isn't much to go on from the project description and I'm curious what FreeBSD devs are looking for specifically. For example, should the entire ldconfig program be ported from OpenBSD (it looks like it's close enough to FreeBSD's to make that suitable), or should just the prebind code be merged into FreeBSD's ldcnfig? Once the project is complete, who should the work be submitted to? Has anyone else worked on this and made any progress? Hi Jesse: I think the intent of the ideas list entry is more a research project than a direct-to-commit project: the question is whether prebinding of some sort would observably help performance for important FreeBSD applications or, for example, the boot process. If so, then certainly the OpenBSD prebinding code is a possible model -- Mac OS X also has prebinding, of course, and it's done quite differently (and probably less reusably from our perspective as they use Mach-O rather than ELF); however, there might be interesting ideas as well. I think therefore I'd structure a project along the following lines: first, you want to establish to what extent synchronous waiting on linkage at run-time is a significant problem. It could be that some combination of hwpmc and DTrace would be the right tools for this. I'd especially pay attention to boot time, since we know that quite a lot of executing takes place then as part of rc.d. I'd also investigate large applications like Firefox, Chrome, KDE, Gnome, etc. KDE already integrates prebinding tricks in its design, but I don't think the others do. Next, I'd dig a bit more into the areas where it's hurting performance -- can you add up all the time spent waiting and cut 10 seconds from boot, or 5 seconds from Firefox startup? Or is the best win going to be .2 seconds in Firefox? Does the OpenBSD optimisation actually address the problem we're experiencing? Perhaps perform some experiments with prebinding-like behaviour, working up to an implementation. It's worth remembering that prebinding comes with some baggage as well, of course. Perhaps less relevant in the world of 64-bit address spaces, but there are some design trade-offs in this department... The most serious issue with prebind is a consistency. It is very easy to get prebind data out of date, and this is esp. easy in the FreeBSD where buildworld and source port upgrades are everyday activity. Before this goes much further, yes, we need a benchmarks that demonstrate that system spends significant time in the symbol resolution for often started images [*], and second, we need to have a workable model for source upgrades. * - so that Firefox, OpenOffice etc do not qualify, IMHO. pgpamzbTnhOCD.pgp Description: PGP signature
Re: Prebind from OpenBSD
On 27 Mar 2011, at 21:04, Kostik Belousov wrote: The most serious issue with prebind is a consistency. It is very easy to get prebind data out of date, and this is esp. easy in the FreeBSD where buildworld and source port upgrades are everyday activity. Before this goes much further, yes, we need a benchmarks that demonstrate that system spends significant time in the symbol resolution for often started images [*], and second, we need to have a workable model for source upgrades. * - so that Firefox, OpenOffice etc do not qualify, IMHO. As I recall, Apple actually does prebinding/etc only for a small set of commonly used libraries -- their libSystem, and then a dynamically determined set of other libraries. Their model puts the libraries into a common shared memory segment that can then be mapped at the same address for all dynamically linked processes in the same chroot. This amortised not only the cost of linking, but also the cost of managing memory mappings (I believe it's a shared submap, but my VM terminology is ... ageing). The downside to their approach is that it requires special kernel support, and probably encodes things that we would prefer not to. However, you could imagine a daemon providing a similar service, in which a file descriptor is made available via a UNIX domain socket to instanced of rtld around the system, which can consistently map it in the same place on each exec. This would also give us an upgrade model that might work better -- the daemon actually prepares the contents of that memory and makes them independent from on-disk storage: when an upgrade is done, you kick the daemon to introduce a new shared memory object, closing the previous one, which causes it to be GC'd when all outstanding processes have exited. Robert___ 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: Unsigned wchar_t
On Mon, Mar 28, 2011 at 08:36:57AM +1300, Andrew Turner wrote: Along with this WCHAR_MIN and WCHAR_MAX are defined both in wchar.h and machine/_stdint.h. I would like to remove the copy from wchar.h and add an include to machine/_stdint.h. Would there be any problems with either of these or is there a better place to put the __wchar_t typedef and define WCHAR_MIN and WCHAR_MAX? The C standard specifies that both wchar.h and stdint.h shall define WCHAR_MIN and WCHAR_MAX. You cannot simply include machine/_stdint.h from wchar.h because the former contains a lot of other macros. Stefan ___ 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: Unsigned wchar_t
On Mon, Mar 28, 2011 at 08:36:57AM +1300, Andrew Turner wrote: Hello hackers@ I'm working on getting FreeBSD working with the ARM EABI. As part of this the Procedure Call Standard for the ARM Architecture (AAPCS) defines wchar_t as an unsigned int. Does someone at ARM actually get paid to define ABIs that are different from what everyone else is doing? Didn't we learn anything from the problems of char vs signed char vs unsigned char? 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: Keeping /etc/localtime up-to-date
On 03/27/2011 08:38, David Wolfskill wrote: It would (in principle) be possible to teach mergemaster(8) how to do this (possibly by including a cookie in ~/.mergemasterrc or /etc/mergemaster.rc to tell it what the reference zoneinfo pathname is), but this type of approach seems sufficiently different from (the bulk of?) what mergemaster does currently that I'm unconvinced that this is reasonable, let alone ideal. Yeah, I wouldn't be enthusiastic about this. :) So it seems to me that requirements would be: * The content of /etc/localtime must provide the appropriate zoneinfo information, even when/usr/share/zoneinfo/* has been modified (or shortly thereafter, in concert with make installworld). This is more along the lines of something that would be easy to work with in mergemaster. If I can tell what file in /usr/share/zoneinfo to compare /etc/localtime to (ideally with fully path), I'm happy to provide a mechanism in mergemaster to make sure it stays up to date. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: Prebind from OpenBSD
-Original Message- From: Robert Watson rwat...@freebsd.org To: Jesse Smith jessefrgsm...@yahoo.ca Cc: freebsd-hackers@freebsd.org Subject: Re: Prebind from OpenBSD Date: Sun, 27 Mar 2011 20:54:18 +0100 (BST) On Sat, 26 Mar 2011, Jesse Smith wrote: I'm interested in working on the Port prebind from OpenBSD project mentioned on the FreeBSD Ideas page. ( http://wiki.freebsd.org/IdeasPage#head-d28cdd95ca1755d5afe63d653cb4926d4bdc99de ) There isn't much to go on from the project description and I'm curious what FreeBSD devs are looking for specifically. For example, should the entire ldconfig program be ported from OpenBSD (it looks like it's close enough to FreeBSD's to make that suitable), or should just the prebind code be merged into FreeBSD's ldcnfig? Once the project is complete, who should the work be submitted to? Has anyone else worked on this and made any progress? Hi Jesse: I think the intent of the ideas list entry is more a research project than a direct-to-commit project: the question is whether prebinding of some sort would observably help performance for important FreeBSD applications or, for example, the boot process. If so, then certainly the OpenBSD prebinding code is a possible model -- Mac OS X also has prebinding, of course, and it's done quite differently (and probably less reusably from our perspective as they use Mach-O rather than ELF); however, there might be interesting ideas as well. I think therefore I'd structure a project along the following lines: first, you want to establish to what extent synchronous waiting on linkage at run-time is a significant problem. It could be that some combination of hwpmc and DTrace would be the right tools for this. I'd especially pay attention to boot time, since we know that quite a lot of executing takes place then as part of rc.d. I'd also investigate large applications like Firefox, Chrome, KDE, Gnome, etc. KDE already integrates prebinding tricks in its design, but I don't think the others do. Next, I'd dig a bit more into the areas where it's hurting performance -- can you add up all the time spent waiting and cut 10 seconds from boot, or 5 seconds from Firefox startup? Or is the best win going to be .2 seconds in Firefox? Does the OpenBSD optimisation actually address the problem we're experiencing? Perhaps perform some experiments with prebinding-like behaviour, working up to an implementation. It's worth remembering that prebinding comes with some baggage as well, of course. Perhaps less relevant in the world of 64-bit address spaces, but there are some design trade-offs in this department... Robert Robert, Thanks very much for the reply. I had thought this was a project/port that was in progress, rather than something waiting on research. Do you know if that's also the case with other projects on the Ideas list? A lot of them don't have many details or contact information associated with them. I'm especially interested in the OpenBSD xlint port. I appreciate you time, Jesse ___ 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
[kl...@thought.org: keyboard click driver:: User-side.]
Note: i meant to include the hacker wizards in this post to the -questions group from 20 mins ago. Here 'tis:: Guys, I have been interested in having a FreeBSD version of the SunOS click utility for decades. --I first discovered that my Sun 3/80 let the keys sound a brief click sound, much softer than ye-olden IBM Selectrics, around 1988-9. I do need the audio feedback. The folks in the wizard sector at Ubuntu turned me onto a python script of about 30 pages of code called keymon.py written by a Scott Kirkwood. The present keymon displays certain graphics when certain keys are hit. Scott does think that his script can include the click sound that I have. My program is in C, it opens the /dev/dsp and output a click via click.h. I am learning python and find it pretty straightforward. I think using Scott's keyboard program with mine can allow me to do just what I want. On the user-side, have clicky keys where necessary. This feedback would help folks using the severely cheep keyboards that are on the notebook class as well as even cheaper laptops for children whose keyboards are nothing put cardboard wrapped in plastic. Typing on a _real_ keyboard can be satisfactory. But when you try it on one of these crappy types, forget it. Just doing several random tests, my fingers do not connect with more than 60-65% of the keys on my EEE-900A. bEcause my shoulder is partly out of socket i can only type so much, so the more people who can check out keymon.py and let me know if it is worth porting to FBSD, the better. Gary Kline kl...@thought.org http://www.thought.org Public Service Unix Journey Toward the Dawn, E-Book: http://www.thought.org The 7.98a release of Jottings: http://jottings.thought.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: Keeping /etc/localtime up-to-date
On Sun, Mar 27, 2011 at 01:31:22PM -0700, Doug Barton wrote: On 03/27/2011 08:38, David Wolfskill wrote: It would (in principle) be possible to teach mergemaster(8) how to do this (possibly by including a cookie in ~/.mergemasterrc or /etc/mergemaster.rc to tell it what the reference zoneinfo pathname is), but this type of approach seems sufficiently different from (the bulk of?) what mergemaster does currently that I'm unconvinced that this is reasonable, let alone ideal. Yeah, I wouldn't be enthusiastic about this. :) Indeed. So it seems to me that requirements would be: * The content of /etc/localtime must provide the appropriate zoneinfo information, even when/usr/share/zoneinfo/* has been modified (or shortly thereafter, in concert with make installworld). This is more along the lines of something that would be easy to work with in mergemaster. Hmm... OK If I can tell what file in /usr/share/zoneinfo to compare /etc/localtime to (ideally with fully path), I'm happy to provide a mechanism in mergemaster to make sure it stays up to date. Well, that's the function that the (hypothetical) cookie in ~/.mergemasterrc or /etc/mergemaster.rc was intended to to provide. It could be a simple shell variable, for example. There are other ways to do it, of course -- e.g., the first time the utility is run, it could actually ask, but then cache the information in some place so it could look there first (and if it finds a cached answer, avoid asking again unless it's told to ignore the cache -- as might be reasonable if the machine is moved to a different time zone. But I tend to favor simplicity. :-) Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpZhc53K08HH.pgp Description: PGP signature
Re: [GSoc] Timeconter Performance Improvements
On Mar 26, 2011, at 8:43 AM, Jing Huang wrote:
Hi,
Thanks for you all sincerely. Under your guidance, I read the
specification of TSC in Intel Manual and learned the hardware feature
of TSC:
Processor families increment the time-stamp counter differently:
• For Pentium M processors (family [06H], models [09H, 0DH]); for Pentium 4
processors, Intel Xeon processors (family [0FH], models [00H, 01H, or 02H]);
and for P6 family processors: the time-stamp counter increments with every
internal processor clock cycle.
• For Pentium 4 processors, Intel Xeon processors (family [0FH],
models [03H and
higher]); for Intel Core Solo and Intel Core Duo processors (family [06H],
model
[0EH]); for the Intel Xeon processor 5100 series and Intel Core 2 Duo
processors
(family [06H], model [0FH]); for Intel Core 2 and Intel Xeon processors
(family
[06H], display_model [17H]); for Intel Atom processors (family [06H],
display_model [1CH]): the time-stamp counter increments at a constant rate.
Maybe we would implement gettimeofday as fellows. Firstly, use cpuid
to find the family and models of current CPU. If the CPU support
constant TSC, we look up the shared page and calculate the precise
time in usermode. If the platform has invariant TSCs, and we just
fallback to a syscall. So, I think a single global shared page maybe
proper.
I think that the userspace portion should be more like:
int kernel_time_type) SECTION(shared);
struct tsc_goo tsc_time_data SECTION(shared);
switch (kernel_time_type) {
case 1:
/* code to use tsc_time_data to return time */
break;
default:
/* call the kernel */
}
I think we should avoid hard-coding lists of CPU families in userland. The
kernel init routines will decide, based on the CPU type and other stuff if this
optimization can be done. This would allow the kernel to update to support new
CPU types without needing to churn libc.
Warner
P.S. The SECTION(shared) notation above just means that the variables are in
the shared page.
On Sat, Mar 26, 2011 at 10:12 PM, John Baldwin j...@freebsd.org wrote:
On Saturday, March 26, 2011 08:16:46 am Peter Jeremy wrote:
On 2011-Mar-25 08:18:38 -0400, John Baldwin j...@freebsd.org wrote:
For modern Intel CPUs you can just assume that the TSCs are in sync across
packages. They also have invariant TSC's meaning that the frequency
doesn't change.
Synchronised P-state invariant TSCs vastly simplify the problem but
not everyone has them. Should the fallback be more complexity to
support per-CPU TSC counts and varying frequencies or a fallback to
reading the time via a syscall?
I think we should just fallback to a syscall in that case. We will also need
to do that if the TSC is not used as the timecounter (or always duplicate the
ntp_adjtime() work we do for the current timecounter for the TSC
timecounter).
Doing this easy case may give us the most bang for the buck, and it is also a
good first milestone. Once that is in place we can decide what the value is
in extending it to support harder variations.
One thing we do need to think about is if the shared page should just export
a
fixed set of global data, or if it should export routines. The latter
approach is more complex, but it makes the ABI boundary between userland and
the kernel more friendly to future changes. I believe Linux does the latter
approach?
--
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
___
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: Keeping /etc/localtime up-to-date
On Sun, Mar 27, 2011 at 03:27:32PM -0700, David Wolfskill wrote: There are other ways to do it, of course -- e.g., the first time the utility is run, it could actually ask, but then cache the information in some place so it could look there first (and if it finds a cached answer, avoid asking again unless it's told to ignore the cache -- as might be reasonable if the machine is moved to a different time zone. That's what tzsetup does in HEAD - the name of the selected timezone file is stored in /var/db/zoneinfo, and tzsetup -r can be used to copy in an updated file: -r Reinstall the zoneinfo file installed last time. The name is obtained from /var/db/zoneinfo. It looks like this hasn't been MFC'd, although I'm not sure why. The change came in from svn rev 198267 by edwin (CC'd). -Ed ___ 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: Keeping /etc/localtime up-to-date
On Mar 27, 2011, at 1:31 PM, Doug Barton wrote: On 03/27/2011 08:38, David Wolfskill wrote: So it seems to me that requirements would be: * The content of /etc/localtime must provide the appropriate zoneinfo information, even when/usr/share/zoneinfo/* has been modified (or shortly thereafter, in concert with make installworld). This is more along the lines of something that would be easy to work with in mergemaster. If I can tell what file in /usr/share/zoneinfo to compare /etc/localtime to (ideally with fully path), I'm happy to provide a mechanism in mergemaster to make sure it stays up to date. The best fix is to first add the ability for date(1) to print out the current timezone name. (E.g., America/Los_Angeles) Then it's trivial for mergemaster to update /etc/localtime; just ask date(1) for the timezone name and copy the correct one over /etc/localtime. Unfortunately, I think it's currently impossible for date(1) to do this because the zoneinfo files don't store that information. This is the real reason Solaris uses a symlink; the value of the symlink gives you the timezone name. FWIW, mergemaster is not the only program that would benefit from a canonical way to obtain the name of the current timezone. Cheers, 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: [GSoc] Timeconter Performance Improvements
On 3/27/2011 5:32 PM, Warner Losh wrote:
On Mar 26, 2011, at 8:43 AM, Jing Huang wrote:
Hi,
Thanks for you all sincerely. Under your guidance, I read the
specification of TSC in Intel Manual and learned the hardware feature
of TSC:
Processor families increment the time-stamp counter differently:
• For Pentium M processors (family [06H], models [09H, 0DH]); for Pentium 4
processors, Intel Xeon processors (family [0FH], models [00H, 01H, or 02H]);
and for P6 family processors: the time-stamp counter increments with every
internal processor clock cycle.
• For Pentium 4 processors, Intel Xeon processors (family [0FH],
models [03H and
higher]); for Intel Core Solo and Intel Core Duo processors (family [06H], model
[0EH]); for the Intel Xeon processor 5100 series and Intel Core 2 Duo processors
(family [06H], model [0FH]); for Intel Core 2 and Intel Xeon processors (family
[06H], display_model [17H]); for Intel Atom processors (family [06H],
display_model [1CH]): the time-stamp counter increments at a constant rate.
Maybe we would implement gettimeofday as fellows. Firstly, use cpuid
to find the family and models of current CPU. If the CPU support
constant TSC, we look up the shared page and calculate the precise
time in usermode. If the platform has invariant TSCs, and we just
fallback to a syscall. So, I think a single global shared page maybe
proper.
I think that the userspace portion should be more like:
int kernel_time_type) SECTION(shared);
struct tsc_goo tsc_time_data SECTION(shared);
switch (kernel_time_type) {
case 1:
/* code to use tsc_time_data to return time */
break;
default:
/* call the kernel */
}
I think we should avoid hard-coding lists of CPU families in userland. The
kernel init routines will decide, based on the CPU type and other stuff if this
optimization can be done. This would allow the kernel to update to support new
CPU types without needing to churn libc.
Warner
P.S. The SECTION(shared) notation above just means that the variables are in
the shared page.
On Sat, Mar 26, 2011 at 10:12 PM, John Baldwinj...@freebsd.org wrote:
On Saturday, March 26, 2011 08:16:46 am Peter Jeremy wrote:
On 2011-Mar-25 08:18:38 -0400, John Baldwinj...@freebsd.org wrote:
For modern Intel CPUs you can just assume that the TSCs are in sync across
packages. They also have invariant TSC's meaning that the frequency
doesn't change.
Synchronised P-state invariant TSCs vastly simplify the problem but
not everyone has them. Should the fallback be more complexity to
support per-CPU TSC counts and varying frequencies or a fallback to
reading the time via a syscall?
I think we should just fallback to a syscall in that case. We will also need
to do that if the TSC is not used as the timecounter (or always duplicate the
ntp_adjtime() work we do for the current timecounter for the TSC timecounter).
Doing this easy case may give us the most bang for the buck, and it is also a
good first milestone. Once that is in place we can decide what the value is
in extending it to support harder variations.
One thing we do need to think about is if the shared page should just export a
fixed set of global data, or if it should export routines. The latter
approach is more complex, but it makes the ABI boundary between userland and
the kernel more friendly to future changes. I believe Linux does the latter
approach?
--
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
___
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
If a user process can perform a rfork(2) or rfork_thread(3) with RFMEM
option, then can't the same page table be active on multiple processors?
Mapping per CPU page(s) to a fixed user addess(es) would only hold the
last switched cpu's information.
x86 architectures use a segment pointer to keep the kernel per cpu
information current.
--Mark Tinguely.
___
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: Keeping /etc/localtime up-to-date
At Sun, 27 Mar 2011 13:31:22 -0700, Doug Barton wrote: This is more along the lines of something that would be easy to work with in mergemaster. If I can tell what file in /usr/share/zoneinfo to compare /etc/localtime to (ideally with fully path), I'm happy to provide a mechanism in mergemaster to make sure it stays up to date. tzsetup(8) creates /var/db/zoneinfo which contains path to the installed zoneinfo file relative to /usr/share/zineinfo/. $ cat /var/db/zoneinfo Asia/Tokyo $ md5 -q /etc/localtime /usr/share/zoneinfo/$(cat /var/db/zoneinfo) f17769e8eb35e7a08cfedfe9b2f6b5ef f17769e8eb35e7a08cfedfe9b2f6b5ef -- kuro ___ 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: [GSoc] Timeconter Performance Improvements
On 3/27/11 3:32 PM, Warner Losh wrote:
On Mar 26, 2011, at 8:43 AM, Jing Huang wrote:
Hi,
Thanks for you all sincerely. Under your guidance, I read the
specification of TSC in Intel Manual and learned the hardware feature
of TSC:
Processor families increment the time-stamp counter differently:
• For Pentium M processors (family [06H], models [09H, 0DH]); for Pentium 4
processors, Intel Xeon processors (family [0FH], models [00H, 01H, or 02H]);
and for P6 family processors: the time-stamp counter increments with every
internal processor clock cycle.
• For Pentium 4 processors, Intel Xeon processors (family [0FH],
models [03H and
higher]); for Intel Core Solo and Intel Core Duo processors (family [06H], model
[0EH]); for the Intel Xeon processor 5100 series and Intel Core 2 Duo processors
(family [06H], model [0FH]); for Intel Core 2 and Intel Xeon processors (family
[06H], display_model [17H]); for Intel Atom processors (family [06H],
display_model [1CH]): the time-stamp counter increments at a constant rate.
Maybe we would implement gettimeofday as fellows. Firstly, use cpuid
to find the family and models of current CPU. If the CPU support
constant TSC, we look up the shared page and calculate the precise
time in usermode. If the platform has invariant TSCs, and we just
fallback to a syscall. So, I think a single global shared page maybe
proper.
I think that the userspace portion should be more like:
int kernel_time_type) SECTION(shared);
struct tsc_goo tsc_time_data SECTION(shared);
switch (kernel_time_type) {
case 1:
/* code to use tsc_time_data to return time */
break;
default:
/* call the kernel */
}
I think we should avoid hard-coding lists of CPU families in userland. The
kernel init routines will decide, based on the CPU type and other stuff if this
optimization can be done. This would allow the kernel to update to support new
CPU types without needing to churn libc.
Warner
P.S. The SECTION(shared) notation above just means that the variables are in
the shared page.
As has been mentioned here and there, the gold-standard way for doing
this is for the kernel to export a special memory region
in elf format that can be linked to with exported kernel sanctioned
code snippets specially tailored for the cpu/OS/binray-format
in question. There is no real security risk to this but potential
upsides are great.
On Sat, Mar 26, 2011 at 10:12 PM, John Baldwinj...@freebsd.org wrote:
On Saturday, March 26, 2011 08:16:46 am Peter Jeremy wrote:
On 2011-Mar-25 08:18:38 -0400, John Baldwinj...@freebsd.org wrote:
For modern Intel CPUs you can just assume that the TSCs are in sync across
packages. They also have invariant TSC's meaning that the frequency
doesn't change.
Synchronised P-state invariant TSCs vastly simplify the problem but
not everyone has them. Should the fallback be more complexity to
support per-CPU TSC counts and varying frequencies or a fallback to
reading the time via a syscall?
I think we should just fallback to a syscall in that case. We will also need
to do that if the TSC is not used as the timecounter (or always duplicate the
ntp_adjtime() work we do for the current timecounter for the TSC timecounter).
Doing this easy case may give us the most bang for the buck, and it is also a
good first milestone. Once that is in place we can decide what the value is
in extending it to support harder variations.
One thing we do need to think about is if the shared page should just export a
fixed set of global data, or if it should export routines. The latter
approach is more complex, but it makes the ABI boundary between userland and
the kernel more friendly to future changes. I believe Linux does the latter
approach?
--
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
___
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
___
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
New Boot-Loader
Hi fellow hackers, I'm designing an open-sourced replacement boot-loader for FreeBSD. I feel that the existing options in the boot-loader menu today can be whittled down significantly with a stateful menu system rather than a single-action item menu system. In designing the new menu, I'd like to get your opinions. From old: FreeBSD 8.1-RELEASE: twitpic.com/4e485w to new: Replacement Boot-Loader: twitpic.com/4e46ol NOTE: The final release will have a single-user mode option. The new menu allows for more flexibility as selecting options 2 (Boot Verbose) or 3 (ACPI Support) independently toggles the status, updates the menu item, and redisplays the menu -- ever-waiting until the user ultimately presses ENTER, 1, or escapes to the prompt and types boot. Thus, one could potentially launch single-user mode with verbosity on and ACPI disabled (if one so desired). In addition, I really tried to capture the essence of the new logo (spent months off-and-on using different conversion programs with different inputs). In the end, I found text-image.com produced the best result. I used the official freebsd.org/logo.html Standard Logo (black and white), cropped (to 122x123) and converted to jpeg with white background. I used an Image Width of 45 in their Convert into ASCII program available here: text-image.com/convert/ascii.html I would be distributing this as an installable package (perhaps in the ports tree if it gains popularity). -- Cheers, Devin Teske - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. - FUN STUFF - -BEGIN GEEK CODE BLOCK- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E- W+++ N? o? K? w@ O M++$ V- PS+++ PE@ Y+ PGP- t(+) 5? X(+) R(-) tv+ b+++ DI+ D+(++) G++ e h r+++ z+++ --END GEEK CODE BLOCK-- http://www.geekcode.com/ - END TRANSMISSION - ___ 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: [GSoc] Timeconter Performance Improvements
On Mar 27, 2011, at 10:29 PM, Julian Elischer wrote:
On 3/27/11 3:32 PM, Warner Losh wrote:
On Mar 26, 2011, at 8:43 AM, Jing Huang wrote:
Hi,
Thanks for you all sincerely. Under your guidance, I read the
specification of TSC in Intel Manual and learned the hardware feature
of TSC:
Processor families increment the time-stamp counter differently:
• For Pentium M processors (family [06H], models [09H, 0DH]); for Pentium
4
processors, Intel Xeon processors (family [0FH], models [00H, 01H, or 02H]);
and for P6 family processors: the time-stamp counter increments with every
internal processor clock cycle.
• For Pentium 4 processors, Intel Xeon processors (family [0FH],
models [03H and
higher]); for Intel Core Solo and Intel Core Duo processors (family [06H],
model
[0EH]); for the Intel Xeon processor 5100 series and Intel Core 2 Duo
processors
(family [06H], model [0FH]); for Intel Core 2 and Intel Xeon processors
(family
[06H], display_model [17H]); for Intel Atom processors (family [06H],
display_model [1CH]): the time-stamp counter increments at a constant rate.
Maybe we would implement gettimeofday as fellows. Firstly, use cpuid
to find the family and models of current CPU. If the CPU support
constant TSC, we look up the shared page and calculate the precise
time in usermode. If the platform has invariant TSCs, and we just
fallback to a syscall. So, I think a single global shared page maybe
proper.
I think that the userspace portion should be more like:
int kernel_time_type) SECTION(shared);
struct tsc_goo tsc_time_data SECTION(shared);
switch (kernel_time_type) {
case 1:
/* code to use tsc_time_data to return time */
break;
default:
/* call the kernel */
}
I think we should avoid hard-coding lists of CPU families in userland. The
kernel init routines will decide, based on the CPU type and other stuff if
this optimization can be done. This would allow the kernel to update to
support new CPU types without needing to churn libc.
Warner
P.S. The SECTION(shared) notation above just means that the variables are
in the shared page.
As has been mentioned here and there, the gold-standard way for doing this is
for the kernel to export a special memory region
in elf format that can be linked to with exported kernel sanctioned code
snippets specially tailored for the cpu/OS/binray-format
in question. There is no real security risk to this but potential upsides are
great.
You'll have to map multiple pages if you do this: one for the data that has to
be exported from the kernel and one that has to be the executable code. I
don't think this is necessarily the gold standard at all. I think it is
overkill that we'll grow to regret.
My method you'll have the code 100% in userland, where it belongs. If you want
to map CPU-type-specific code, add it to ld.so.
Warner
On Sat, Mar 26, 2011 at 10:12 PM, John Baldwinj...@freebsd.org wrote:
On Saturday, March 26, 2011 08:16:46 am Peter Jeremy wrote:
On 2011-Mar-25 08:18:38 -0400, John Baldwinj...@freebsd.org wrote:
For modern Intel CPUs you can just assume that the TSCs are in sync
across
packages. They also have invariant TSC's meaning that the frequency
doesn't change.
Synchronised P-state invariant TSCs vastly simplify the problem but
not everyone has them. Should the fallback be more complexity to
support per-CPU TSC counts and varying frequencies or a fallback to
reading the time via a syscall?
I think we should just fallback to a syscall in that case. We will also
need
to do that if the TSC is not used as the timecounter (or always duplicate
the
ntp_adjtime() work we do for the current timecounter for the TSC
timecounter).
Doing this easy case may give us the most bang for the buck, and it is
also a
good first milestone. Once that is in place we can decide what the value
is
in extending it to support harder variations.
One thing we do need to think about is if the shared page should just
export a
fixed set of global data, or if it should export routines. The latter
approach is more complex, but it makes the ABI boundary between userland
and
the kernel more friendly to future changes. I believe Linux does the
latter
approach?
--
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
___
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
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
Re: New Boot-Loader
On Mar 27, 2011, at 9:53 PM, Super Bisquit wrote: And what if I need to boot into single user mode? I'll forgive the top-post, and I'll even forgive that you missed the below NOTE: The final release will have a single-user mode option. Here it is with single-user mode option: twitpic.com/4e6gu1 -- Devin On Mon, Mar 28, 2011 at 12:48 AM, Devin Teske dte...@vicor.com wrote: Hi fellow hackers, I'm designing an open-sourced replacement boot-loader for FreeBSD. I feel that the existing options in the boot-loader menu today can be whittled down significantly with a stateful menu system rather than a single-action item menu system. In designing the new menu, I'd like to get your opinions. From old: FreeBSD 8.1-RELEASE: twitpic.com/4e485w to new: Replacement Boot-Loader: twitpic.com/4e46ol NOTE: The final release will have a single-user mode option. The new menu allows for more flexibility as selecting options 2 (Boot Verbose) or 3 (ACPI Support) independently toggles the status, updates the menu item, and redisplays the menu -- ever-waiting until the user ultimately presses ENTER, 1, or escapes to the prompt and types boot. Thus, one could potentially launch single-user mode with verbosity on and ACPI disabled (if one so desired). In addition, I really tried to capture the essence of the new logo (spent months off-and-on using different conversion programs with different inputs). In the end, I found text-image.com produced the best result. I used the official freebsd.org/logo.html Standard Logo (black and white), cropped (to 122x123) and converted to jpeg with white background. I used an Image Width of 45 in their Convert into ASCII program available here: text-image.com/convert/ascii.html I would be distributing this as an installable package (perhaps in the ports tree if it gains popularity). -- Cheers, Devin Teske - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. - FUN STUFF - -BEGIN GEEK CODE BLOCK- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E- W+++ N? o? K? w@ O M++$ V- PS+++ PE@ Y+ PGP- t(+) 5? X(+) R(-) tv+ b+++ DI+ D+(++) G++ e h r+++ z+++ --END GEEK CODE BLOCK-- http://www.geekcode.com/ - END TRANSMISSION - ___ 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 ___ 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: New Boot-Loader
And what if I need to boot into single user mode? On Mon, Mar 28, 2011 at 12:48 AM, Devin Teske dte...@vicor.com wrote: Hi fellow hackers, I'm designing an open-sourced replacement boot-loader for FreeBSD. I feel that the existing options in the boot-loader menu today can be whittled down significantly with a stateful menu system rather than a single-action item menu system. In designing the new menu, I'd like to get your opinions. From old: FreeBSD 8.1-RELEASE: twitpic.com/4e485w to new: Replacement Boot-Loader: twitpic.com/4e46ol NOTE: The final release will have a single-user mode option. The new menu allows for more flexibility as selecting options 2 (Boot Verbose) or 3 (ACPI Support) independently toggles the status, updates the menu item, and redisplays the menu -- ever-waiting until the user ultimately presses ENTER, 1, or escapes to the prompt and types boot. Thus, one could potentially launch single-user mode with verbosity on and ACPI disabled (if one so desired). In addition, I really tried to capture the essence of the new logo (spent months off-and-on using different conversion programs with different inputs). In the end, I found text-image.com produced the best result. I used the official freebsd.org/logo.html Standard Logo (black and white), cropped (to 122x123) and converted to jpeg with white background. I used an Image Width of 45 in their Convert into ASCII program available here: text-image.com/convert/ascii.html I would be distributing this as an installable package (perhaps in the ports tree if it gains popularity). -- Cheers, Devin Teske - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. - FUN STUFF - -BEGIN GEEK CODE BLOCK- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E- W+++ N? o? K? w@ O M++$ V- PS+++ PE@ Y+ PGP- t(+) 5? X(+) R(-) tv+ b+++ DI+ D+(++) G++ e h r+++ z+++ --END GEEK CODE BLOCK-- http://www.geekcode.com/ - END TRANSMISSION - ___ 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 ___ 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: New Boot-Loader
On Mar 27, 2011, at 10:48 PM, Devin Teske wrote: Replacement Boot-Loader: twitpic.com/4e46ol NOTE: The final release will have a single-user mode option. This looks really cool. Nice to see a fresh look for the boot loader... The new menu allows for more flexibility as selecting options 2 (Boot Verbose) or 3 (ACPI Support) independently toggles the status, updates the menu item, and redisplays the menu -- ever-waiting until the user ultimately presses ENTER, 1, or escapes to the prompt and types boot. Thus, one could potentially launch single-user mode with verbosity on and ACPI disabled (if one so desired). In addition, I really tried to capture the essence of the new logo (spent months off-and-on using different conversion programs with different inputs). In the end, I found text-image.com produced the best result. I used the official freebsd.org/logo.html Standard Logo (black and white), cropped (to 122x123) and converted to jpeg with white background. I used an Image Width of 45 in their Convert into ASCII program available here: text-image.com/convert/ascii.html This looks cool... I would be distributing this as an installable package (perhaps in the ports tree if it gains popularity). That would be nice... Warner -- Cheers, Devin Teske - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. - FUN STUFF - -BEGIN GEEK CODE BLOCK- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E- W+++ N? o? K? w@ O M++$ V- PS+++ PE@ Y+ PGP- t(+) 5? X(+) R(-) tv+ b+++ DI+ D+(++) G++ e h r+++ z+++ --END GEEK CODE BLOCK-- http://www.geekcode.com/ - END TRANSMISSION - ___ 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 ___ 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
