Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?)
1) XML output from some sysctl variables. It isn't just stupid. It's sad. 2) bsdlabel -e allows editing only when NONE of partitions are open/mounted, in spite that they are not modified. In FreeBSD 6 it allowed editing everytime and all worked. Preventing people doing stupid things would prevent doing clever things. ^ Bsdlabel was a monstrosity that required a calculator to hand to do anything useful. Gpart on the other hand is easily scriptable. off topic. ___ 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: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?)
to me...man pages are -reference- material. They are not intended to be the 'right way' to learn something, but instead as a quick reference guide. manual pages are intended to PROPERLY describe how program/function etc. operates. Of course, I doubt anyone can make a case for the 'one true right way' to learn FreeBSD. True. I would never teach someone to read the man pages as a way to familiarize themselves with...say...geom(8). (In fact, I'd love to find some why? The notion of a 'new user' is unfortunately too wide of a category to target documentation to. The problem of today is persistent new user. New user since first time touched computer. A secretary who's never seen anything but windows, a 5 year old child, and a fresh PhD in computer science might all fit this category. Each of these people requires different levels of teaching. Secretary should not be FreeBSD admin, while of course can be FreeBSD user. Unix makes clear distinction between user and admin. Modern computing style blurs it. Everytime I see these discussions my mind flashes to a web based wiki where everyone writes helpful information (like the Emacs Wiki) on various topics and it's fairly well indexed so you can see related ideas. Does something like this exist for FreeBSD? No idea. What i HATE in very modern software is wiki-style documentation. 4) Adding features that are not really finished and in working state. gjournal is an example, background fsck is another (everyone actually ends in background_fsck=NO) Well you have me there, I thought background fsck worked...I just left it on because it's set like that in /etc/defaults/rc.conf. snapshots do crash on big filesystems. And after background fsck often you will find more errors by foreground fsck. Anyway it is not a problem really. Just don't make bulky virtual volumes of 100 disks, as it is not just slow to fsck but dangerous. if your server works for people that cannot stand half an hour of downtime then change to 0 all /etc/fstab positions except of most important, then after a crash do fsck after worktime. with softupdates it is generally safe to run filesystem without fsck for some time. Of course in the same time where are hundreds of good things done, and we all know it. But if people won't understand a problem NOW and fight it, it will become worse. If everyone is busy fighting evil, who is left to create the good? :) First good must be needed. Now good is defined by democratic means buy herd of persistent newbies. Doing nothing is actually better than create new goods like that. ___ 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
Is there a reason that xhci isn't mentioned in NOTES in 8-stable?
The xhci code in 8-stable works, but it's not mentioned in the NOTES files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is hooked up in sys/modules/usb/Makefile, and that's how I've been using it so far. Is it not possible to compile this code into the kernel? Doug -- Change is hard. ___ 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: Is there a reason that xhci isn't mentioned in NOTES in 8-stable?
On Thursday 19 July 2012 11:14:42 Doug Barton wrote: The xhci code in 8-stable works, but it's not mentioned in the NOTES files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is hooked up in sys/modules/usb/Makefile, and that's how I've been using it so far. Is it not possible to compile this code into the kernel? Doug Yes, you can compile xhci into the kernel using device xhci. Not sure who's responsible for updating NOTES. --HPS ___ 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: Is there a reason that xhci isn't mentioned in NOTES in 8-stable?
On 07/19/2012 02:17, Hans Petter Selasky wrote:
On Thursday 19 July 2012 11:14:42 Doug Barton wrote:
The xhci code in 8-stable works, but it's not mentioned in the NOTES
files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is
hooked up in sys/modules/usb/Makefile, and that's how I've been using it
so far. Is it not possible to compile this code into the kernel?
Doug
Yes, you can compile xhci into the kernel using device xhci. Not sure who's
responsible for updating NOTES.
That would be you. :) (Since AFAICS you added the code.) It should
almost certainly also be in the GENERIC files for the systems to which
it applies.
In HEAD and stable/9 it's in sys/conf/NOTES, and
{amd64|i386}/conf/GENERIC; so the same should probably go for stable/8.
Not sure if the code works on stable/7 or not, but we're going to do
another release in stable/8 so it should be updated there for sure.
Doug
--
Change is hard.
___
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: Is there a reason that xhci isn't mentioned in NOTES in 8-stable?
On Thursday 19 July 2012 11:38:11 Doug Barton wrote:
On 07/19/2012 02:17, Hans Petter Selasky wrote:
On Thursday 19 July 2012 11:14:42 Doug Barton wrote:
The xhci code in 8-stable works, but it's not mentioned in the NOTES
files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is
hooked up in sys/modules/usb/Makefile, and that's how I've been using it
so far. Is it not possible to compile this code into the kernel?
Doug
Yes, you can compile xhci into the kernel using device xhci. Not sure
who's responsible for updating NOTES.
That would be you. :) (Since AFAICS you added the code.) It should
almost certainly also be in the GENERIC files for the systems to which
it applies.
In HEAD and stable/9 it's in sys/conf/NOTES, and
{amd64|i386}/conf/GENERIC; so the same should probably go for stable/8.
Not sure if the code works on stable/7 or not, but we're going to do
another release in stable/8 so it should be updated there for sure.
I've MFC'ed the NOTES bit, but I'm not sure about the GENERIC bit.
http://svn.freebsd.org/changeset/base/238616
--HPS
___
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: Is there a reason that xhci isn't mentioned in NOTES in 8-stable?
On 07/19/2012 03:29, Hans Petter Selasky wrote:
On Thursday 19 July 2012 11:38:11 Doug Barton wrote:
On 07/19/2012 02:17, Hans Petter Selasky wrote:
On Thursday 19 July 2012 11:14:42 Doug Barton wrote:
The xhci code in 8-stable works, but it's not mentioned in the NOTES
files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is
hooked up in sys/modules/usb/Makefile, and that's how I've been using it
so far. Is it not possible to compile this code into the kernel?
Doug
Yes, you can compile xhci into the kernel using device xhci. Not sure
who's responsible for updating NOTES.
That would be you. :) (Since AFAICS you added the code.) It should
almost certainly also be in the GENERIC files for the systems to which
it applies.
In HEAD and stable/9 it's in sys/conf/NOTES, and
{amd64|i386}/conf/GENERIC; so the same should probably go for stable/8.
Not sure if the code works on stable/7 or not, but we're going to do
another release in stable/8 so it should be updated there for sure.
I've MFC'ed the NOTES bit, but I'm not sure about the GENERIC bit.
http://svn.freebsd.org/changeset/base/238616
Thanks! What are your concerns about adding it to GENERIC?
--
Change is hard.
___
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: Is there a reason that xhci isn't mentioned in NOTES in 8-stable?
On Thursday 19 July 2012 12:34:34 Doug Barton wrote:
On 07/19/2012 03:29, Hans Petter Selasky wrote:
On Thursday 19 July 2012 11:38:11 Doug Barton wrote:
On 07/19/2012 02:17, Hans Petter Selasky wrote:
On Thursday 19 July 2012 11:14:42 Doug Barton wrote:
The xhci code in 8-stable works, but it's not mentioned in the NOTES
files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is
hooked up in sys/modules/usb/Makefile, and that's how I've been using
it so far. Is it not possible to compile this code into the kernel?
Doug
Yes, you can compile xhci into the kernel using device xhci. Not sure
who's responsible for updating NOTES.
That would be you. :) (Since AFAICS you added the code.) It should
almost certainly also be in the GENERIC files for the systems to which
it applies.
In HEAD and stable/9 it's in sys/conf/NOTES, and
{amd64|i386}/conf/GENERIC; so the same should probably go for stable/8.
Not sure if the code works on stable/7 or not, but we're going to do
another release in stable/8 so it should be updated there for sure.
I've MFC'ed the NOTES bit, but I'm not sure about the GENERIC bit.
http://svn.freebsd.org/changeset/base/238616
Thanks! What are your concerns about adding it to GENERIC?
Hi,
I don't see any problems at the present. I think all issues have been ironed
out including the 32/64 byte context sizes. From what I'm aware the XHCI
driver in 8-stable should be the same like in 9- and 10- except from a recent
patch done by mav @. This patch should not make a big difference, except for
INTEL patherpoint devices.
--HPS
___
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: kqueue periodic timer confusion
On Fri, 2012-07-13 at 07:22 -0500, Davide Italiano wrote:
On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin j...@freebsd.org wrote:
On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin j...@freebsd.org wrote:
On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote:
On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
Hi,
Sorry about this repost but I'm confused about the responses I
received
in my last post so I'm looking for some clarification.
Specifically, I though I could use the kqueue timer as
essentially a
drop in replacement for linuxfd_create/read, but was surprised
that
the accuracy of the kqueue timer is much less than what I need
for my
application.
So my confusion at this point is whether this is consider to be a
bug or
feature?
Here's some test code if you want to verify the problem:
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
#include errno.h
#include sys/types.h
#include sys/event.h
#include sys/time.h
int
main(void)
{
int i,msec;
int kq,nev;
struct kevent inqueue;
struct kevent outqueue;
struct timeval start,end;
if ((kq = kqueue()) == -1) {
fprintf(stderr, kqueue error!? errno = %s,
strerror(errno));
exit(EXIT_FAILURE);
}
EV_SET(inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0,
20, 0);
gettimeofday(start, 0);
for (i = 0; i 50; i++) {
if ((nev = kevent(kq, inqueue, 1, outqueue, 1,
NULL)) ==
-1) {
fprintf(stderr, kevent error!? errno =
%s,
strerror(errno));
exit(EXIT_FAILURE);
} else if (outqueue.flags EV_ERROR) {
fprintf(stderr, EV_ERROR: %s\n,
strerror(outqueue.data));
exit(EXIT_FAILURE);
}
}
gettimeofday(end, 0);
msec = ((end.tv_sec - start.tv_sec) * 1000) + (((100 +
end.tv_usec - start.tv_usec) / 1000) - 1000);
printf(msec = %d\n, msec);
close(kq);
return EXIT_SUCCESS;
}
What you are seeing is just the way FreeBSD currently works.
Sleeping (in most all of its various forms, and I've just looked at
the
kevent code to verify this is true there) is handled by converting
the
amount of time to sleep (usually specified in a timeval or timespec
struct) to a count of timer ticks, using an internal routine called
tvtohz() in kern/kern_time.c. That routine rounds up by one tick to
account for the current tick. Whether that's a good idea or not (it
probably was once, and probably not anymore) it's how things
currently
work, and could explain the fairly consistant +1ms you're seeing.
This is all true, but mostly irrelevant for his case. EVFILT_TIMER
installs a periodic callout that executes KNOTE() and then resets
itself (via
callout_reset()) each time it runs. This should generally be closer
to
regulary spaced intervals than something that does:
In what way is it irrelevant? That is, what did I miss? It appears to
me that the next callout is scheduled by calling timertoticks() passing
a count of milliseconds, that count is converted to a struct timeval and
passed to tvtohz() which is where the +1 adjustment happens. If you ask
for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms.
There is some time, likely a small number of microseconds, that you've
consumed of the current tick, and that's what the +1 in tvtohz() is
supposed to account for according to the comments.
The tvtohz() routine both rounds up in the usual way (value+tick-1)/tick
and then adds one tick on top of that. That seems not quite right to
me, except that it is a way to g'tee that you don't return early, and
that is the one promise made by sleep routines on any OS; those magical
at least words always appear in the docs.
Actually what I'm missing (that I know of) is how the scheduler works.
Maybe the +1 adjustment to account for the fraction of the current tick
you've already consumed is the right thing to do, even when that
fraction is 1uS or less of a 1mS tick. That would depend on scheduler
behavior that I know nothing about.
Oh. My bad, sorry. You are correct. It is a bug to use +1 in
Re: kqueue periodic timer confusion
On Thu, Jul 19, 2012 at 5:06 PM, Paul Albrecht albre...@glccom.com wrote:
On Fri, 2012-07-13 at 07:22 -0500, Davide Italiano wrote:
On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin j...@freebsd.org wrote:
On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin j...@freebsd.org wrote:
On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote:
On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
Hi,
Sorry about this repost but I'm confused about the responses I
received
in my last post so I'm looking for some clarification.
Specifically, I though I could use the kqueue timer as
essentially a
drop in replacement for linuxfd_create/read, but was surprised
that
the accuracy of the kqueue timer is much less than what I need
for my
application.
So my confusion at this point is whether this is consider to be
a bug or
feature?
Here's some test code if you want to verify the problem:
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
#include errno.h
#include sys/types.h
#include sys/event.h
#include sys/time.h
int
main(void)
{
int i,msec;
int kq,nev;
struct kevent inqueue;
struct kevent outqueue;
struct timeval start,end;
if ((kq = kqueue()) == -1) {
fprintf(stderr, kqueue error!? errno = %s,
strerror(errno));
exit(EXIT_FAILURE);
}
EV_SET(inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0,
20, 0);
gettimeofday(start, 0);
for (i = 0; i 50; i++) {
if ((nev = kevent(kq, inqueue, 1, outqueue, 1,
NULL)) ==
-1) {
fprintf(stderr, kevent error!? errno =
%s,
strerror(errno));
exit(EXIT_FAILURE);
} else if (outqueue.flags EV_ERROR) {
fprintf(stderr, EV_ERROR: %s\n,
strerror(outqueue.data));
exit(EXIT_FAILURE);
}
}
gettimeofday(end, 0);
msec = ((end.tv_sec - start.tv_sec) * 1000) + (((100
+
end.tv_usec - start.tv_usec) / 1000) - 1000);
printf(msec = %d\n, msec);
close(kq);
return EXIT_SUCCESS;
}
What you are seeing is just the way FreeBSD currently works.
Sleeping (in most all of its various forms, and I've just looked
at the
kevent code to verify this is true there) is handled by converting
the
amount of time to sleep (usually specified in a timeval or timespec
struct) to a count of timer ticks, using an internal routine called
tvtohz() in kern/kern_time.c. That routine rounds up by one tick
to
account for the current tick. Whether that's a good idea or not
(it
probably was once, and probably not anymore) it's how things
currently
work, and could explain the fairly consistant +1ms you're seeing.
This is all true, but mostly irrelevant for his case. EVFILT_TIMER
installs a periodic callout that executes KNOTE() and then resets
itself (via
callout_reset()) each time it runs. This should generally be closer
to
regulary spaced intervals than something that does:
In what way is it irrelevant? That is, what did I miss? It appears to
me that the next callout is scheduled by calling timertoticks() passing
a count of milliseconds, that count is converted to a struct timeval
and
passed to tvtohz() which is where the +1 adjustment happens. If you
ask
for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms.
There is some time, likely a small number of microseconds, that you've
consumed of the current tick, and that's what the +1 in tvtohz() is
supposed to account for according to the comments.
The tvtohz() routine both rounds up in the usual way
(value+tick-1)/tick
and then adds one tick on top of that. That seems not quite right to
me, except that it is a way to g'tee that you don't return early, and
that is the one promise made by sleep routines on any OS; those magical
at least words always appear in the docs.
Actually what I'm missing (that I know of) is how the scheduler works.
Maybe the +1 adjustment to account for the fraction of the current tick
you've already consumed is the right thing to do, even when that
fraction is 1uS or less of a 1mS tick. That would depend on scheduler
Awful FreeBSD 9 block IO performance in KVM
Dear Everyone, FreeBSD 9 has awful block IO performance in KVM. I have experienced it and others have experienced it. Someone posted slides to slideshare with benchmarks documenting it: http://www.slideshare.net/TakeshiHasegawa1/runningfreebsdonlinuxkvm Slides 13 and 20 are particular eye openers. Does anyone know what is wrong? Yours truly, Richard Yao signature.asc Description: OpenPGP digital signature
Re: kqueue periodic timer confusion
on 19/07/2012 18:11 Davide Italiano said the following:
On Thu, Jul 19, 2012 at 5:06 PM, Paul Albrecht albre...@glccom.com wrote:
On Fri, 2012-07-13 at 07:22 -0500, Davide Italiano wrote:
On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin j...@freebsd.org wrote:
On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin j...@freebsd.org wrote:
On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote:
On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
Hi,
Sorry about this repost but I'm confused about the responses I
received
in my last post so I'm looking for some clarification.
Specifically, I though I could use the kqueue timer as essentially a
drop in replacement for linuxfd_create/read, but was surprised that
the accuracy of the kqueue timer is much less than what I need for my
application.
So my confusion at this point is whether this is consider to be a
bug or
feature?
Here's some test code if you want to verify the problem:
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
#include errno.h
#include sys/types.h
#include sys/event.h
#include sys/time.h
int
main(void)
{
int i,msec;
int kq,nev;
struct kevent inqueue;
struct kevent outqueue;
struct timeval start,end;
if ((kq = kqueue()) == -1) {
fprintf(stderr, kqueue error!? errno = %s,
strerror(errno));
exit(EXIT_FAILURE);
}
EV_SET(inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20,
0);
gettimeofday(start, 0);
for (i = 0; i 50; i++) {
if ((nev = kevent(kq, inqueue, 1, outqueue, 1,
NULL)) ==
-1) {
fprintf(stderr, kevent error!? errno = %s,
strerror(errno));
exit(EXIT_FAILURE);
} else if (outqueue.flags EV_ERROR) {
fprintf(stderr, EV_ERROR: %s\n,
strerror(outqueue.data));
exit(EXIT_FAILURE);
}
}
gettimeofday(end, 0);
msec = ((end.tv_sec - start.tv_sec) * 1000) + (((100 +
end.tv_usec - start.tv_usec) / 1000) - 1000);
printf(msec = %d\n, msec);
close(kq);
return EXIT_SUCCESS;
}
What you are seeing is just the way FreeBSD currently works.
Sleeping (in most all of its various forms, and I've just looked at
the
kevent code to verify this is true there) is handled by converting the
amount of time to sleep (usually specified in a timeval or timespec
struct) to a count of timer ticks, using an internal routine called
tvtohz() in kern/kern_time.c. That routine rounds up by one tick to
account for the current tick. Whether that's a good idea or not (it
probably was once, and probably not anymore) it's how things currently
work, and could explain the fairly consistant +1ms you're seeing.
This is all true, but mostly irrelevant for his case. EVFILT_TIMER
installs a periodic callout that executes KNOTE() and then resets
itself (via
callout_reset()) each time it runs. This should generally be closer to
regulary spaced intervals than something that does:
In what way is it irrelevant? That is, what did I miss? It appears to
me that the next callout is scheduled by calling timertoticks() passing
a count of milliseconds, that count is converted to a struct timeval and
passed to tvtohz() which is where the +1 adjustment happens. If you ask
for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms.
There is some time, likely a small number of microseconds, that you've
consumed of the current tick, and that's what the +1 in tvtohz() is
supposed to account for according to the comments.
The tvtohz() routine both rounds up in the usual way (value+tick-1)/tick
and then adds one tick on top of that. That seems not quite right to
me, except that it is a way to g'tee that you don't return early, and
that is the one promise made by sleep routines on any OS; those magical
at least words always appear in the docs.
Actually what I'm missing (that I know of) is how the scheduler works.
Maybe the +1 adjustment to account for the fraction of the current tick
you've already consumed is the right thing to do, even when that
fraction is 1uS or less of a 1mS tick. That would depend on scheduler
behavior that I know nothing about.
Oh. My bad, sorry. You are correct. It is a bug to use +1 in this
case. That is, the +1 makes sense when you are computing a one-time
delta
for things like nanosleep(). It is incorrect when computing a periodic
delta such as for computing the interval for an itimer (setitimer) or
EVFILT_TIMER().
Hah, setitimer()'s callout (realitexpire) uses tvtohz - 1:
sys/kern/kern_time.c:
/*
* Real interval timer expired:
* send
