Re: Switching to [KMGTPE]i prefixes?
The new flag is '0x0f' but it should be '0x40' since that's a bit field... I did some doodling with this as well in my tree, and came up with something similar. I had an ifdef that forced the new mode, but I was never happy with the results. Warner On Mar 24, 2011, at 7:55 PM, Alexander Best wrote: > here's a rough draft. it introduces a new flag called HN_IEC_PREFIXES so > nothing should get broken and each utility can decide for itself whether to > use > the SI binary, SI decimal or the IEC certified prefixes. > > another possibility would be to #ifdef the extra code. this would offer the > possibility to turn the new code on or off without having to adjust any > utilities. of course this behaviour should be disabled by default in order to > maintain compatibility. > > cheers. > alex > > -- > a13x > ___ > 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: Switching to [KMGTPE]i prefixes?
On Fri, 25 Mar 2011 00:21:15 + Alexander Best wrote: > i hacked up humanized_number(3) a bit in order to produce the > following df(1) output: > [...] > 4.2Gi 4.2Gi 0B 100% 0 0 100% /media/dvd I don't know if it's correct, but Snow Leopard uses "Bi" for bytes. -- Bruce Cran ___ 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: Switching to [KMGTPE]i prefixes?
here is a revised patch. it also includes the necessary changes to the
humanize_number(3) man page.
cheers.
alex
--
a13x
diff --git a/lib/libutil/humanize_number.3 b/lib/libutil/humanize_number.3
index 82925ba..841da3f 100644
--- a/lib/libutil/humanize_number.3
+++ b/lib/libutil/humanize_number.3
@@ -68,17 +68,22 @@ then divide
by 1024 until it will.
In this case, prefix
.Fa suffix
-with the appropriate SI designator.
+with the appropriate SI (or IEC) designator.
The
.Fn humanize_number
function
-follows the traditional computer science conventions rather than the proposed
-SI power of two convention.
+follows the traditional computer science conventions by default rather than
the proposed
+IEC power of two convention or the power of ten notion.
+This behaviour however can be altered by the
+.Dv HN_DIVISOR_1000
+and
+.Dv HN_IEC_PREFIXES
+flags.
.Pp
-The prefixes are:
+The default prefixes are:
.Bl -column "Prefix" "Description" "100" -offset indent
.It Sy "Prefix" Ta Sy "Description" Ta Sy "Multiplier" Ta Sy "Multiplier 1000x"
-.It Li k Ta No kilo Ta 1024 Ta 1000
+.It Li * Ta No kilo Ta 1024 Ta 1000
.It Li M Ta No mega Ta 1048576 Ta 100
.It Li G Ta No giga Ta 1073741824 Ta 10
.It Li T Ta No tera Ta 1099511627776 Ta 1
@@ -86,6 +91,19 @@ The prefixes are:
.It Li E Ta No exa Ta 1152921504606846976 Ta 100
.El
.Pp
+* An uppercase K indicates a power of two, a lowercase k a power of ten.
+.Pp
+The IEC power of two (IEC 8-13) prefixes are:
+.Bl -column "Prefix" "Description" "100" -offset indent
+.It Sy "Prefix" Ta Sy "Description" Ta Sy "Multiplier"
+.It Li Ki Ta No kibi Ta 1024
+.It Li Mi Ta No mebi Ta 1048576
+.It Li Gi Ta No gibi Ta 1073741824
+.It Li Ti Ta No tebi Ta 1099511627776
+.It Li Pi Ta No pebi Ta 1125899906842624
+.It Li Ei Ta No exbi Ta 1152921504606846976
+.El
+.Pp
The
.Fa len
argument must be at least 4 plus the length of
@@ -127,6 +145,11 @@ Use
Divide
.Fa number
with 1000 instead of 1024.
+.It Dv HN_IEC_PREFIXES
+Use the IEC notion of prefixes (Ki, Mi, Gi...).
+This flag has no effect when
+.Dv HN_DIVISOR_1000
+is also specified.
.El
.Sh RETURN VALUES
The
@@ -148,3 +171,7 @@ function first appeared in
.Nx 2.0
and then in
.Fx 5.3 .
+The
+.Dv HN_IEC_PREFIXES
+flag was introduced in
+.Fx 9.0 .
diff --git a/lib/libutil/humanize_number.c b/lib/libutil/humanize_number.c
index 75bcb46..efa06cb 100644
--- a/lib/libutil/humanize_number.c
+++ b/lib/libutil/humanize_number.c
@@ -47,7 +47,7 @@ humanize_number(char *buf, size_t len, int64_t quotient,
const char *suffix, int scale, int flags)
{
const char *prefixes, *sep;
- int i, r, remainder, maxscale, s1, s2, sign;
+ int i, r, remainder, maxscale, s1, s2, shift, sign;
int64_t divisor, max;
size_t baselen;
@@ -57,26 +57,41 @@ humanize_number(char *buf, size_t len, int64_t quotient,
remainder = 0;
+ /*
+* With HN_DIVISOR_1000 defined, SI prefixes for decimal multiplies
+* are used. Without this flag, the raditional power of two prefixes
+* are used. If however HN_IEC_PREFIXES is defined, the power of
+* two prefixes recommended by the International Electrotechnical
+* Commission (IEC) in IEC 8-3 (superseeding IEC 60027-2)
+* (i.e. Ki, Mi, Gi...) are used.
+*
+* Please note that HN_DIVISOR_1000 takes priority over HN_IEC_PREFIXES.
+* The default behavior is to use the traditional power of two prefixes.
+*/
if (flags & HN_DIVISOR_1000) {
- /* SI for decimal multiplies */
divisor = 1000;
+ shift = 1;
if (flags & HN_B)
prefixes = "B\0k\0M\0G\0T\0P\0E";
else
prefixes = "\0\0k\0M\0G\0T\0P\0E";
+ } else if (flags & HN_IEC_PREFIXES) {
+ divisor = 1024;
+ shift = 2;
+ if (flags & HN_B)
+ prefixes = "B\0\0\0Ki\0\0Mi\0\0Gi\0\0Ti\0\0Pi\0\0Ei";
+ else
+ prefixes = "\0\0\0\0Ki\0\0Mi\0\0Gi\0\0Ti\0\0Pi\0\0Ei";
} else {
- /*
-* binary multiplies
-* XXX IEC 60027-2 recommends Ki, Mi, Gi...
-*/
divisor = 1024;
+ shift = 1;
if (flags & HN_B)
prefixes = "B\0K\0M\0G\0T\0P\0E";
else
prefixes = "\0\0K\0M\0G\0T\0P\0E";
}
-#defineSCALE2PREFIX(scale) (&prefixes[(scale) << 1])
+#defineSCALE2PREFIX(scale) (&prefixes[(scale) << shift])
maxscale = 7;
if (scale >= maxscale &&
@@ -102,6 +117,10 @@ humanize_number(char *buf, size_t len, int64_t quotient,
sep = " ";
baselen++;
}
+ if (flags & HN_IEC_PREFIXES) {
+ b
Re: Switching to [KMGTPE]i prefixes?
here's a rough draft. it introduces a new flag called HN_IEC_PREFIXES so
nothing should get broken and each utility can decide for itself whether to use
the SI binary, SI decimal or the IEC certified prefixes.
another possibility would be to #ifdef the extra code. this would offer the
possibility to turn the new code on or off without having to adjust any
utilities. of course this behaviour should be disabled by default in order to
maintain compatibility.
cheers.
alex
--
a13x
diff --git a/lib/libutil/humanize_number.c b/lib/libutil/humanize_number.c
index 75bcb46..b6677c3 100644
--- a/lib/libutil/humanize_number.c
+++ b/lib/libutil/humanize_number.c
@@ -47,7 +47,7 @@ humanize_number(char *buf, size_t len, int64_t quotient,
const char *suffix, int scale, int flags)
{
const char *prefixes, *sep;
- int i, r, remainder, maxscale, s1, s2, sign;
+ int i, r, remainder, maxscale, s1, s2, shift, sign;
int64_t divisor, max;
size_t baselen;
@@ -57,26 +57,45 @@ humanize_number(char *buf, size_t len, int64_t quotient,
remainder = 0;
+ /*
+* With HN_DIVISOR_1000 defined in flags, SI prefixes for decimal
+* multiplies are being used. Without this flag, SI prefixes for
+* binary multiplies are being used. If however HN_IEC_PREFIXES is
+* defined in flags, the prefixes recommended by the International
+* Electrotechnical Commission (IEC) for binary multiplies in
+* IEC 8-3 (superseeding IEC 60027-2) (i.e. Ki, Mi, Gi...) are
+* being used.
+*
+* Please note that HN_DIVISOR_1000 and HN_IEC_PREFIXES are mutually
+* exclusive. The default behavior is to use SI prefixes for binary
+* multiplies.
+*/
+ if ((flags & HN_DIVISOR_1000) && (flags & HN_IEC_PREFIXES))
+ return (-1);
if (flags & HN_DIVISOR_1000) {
- /* SI for decimal multiplies */
divisor = 1000;
+ shift = 1;
if (flags & HN_B)
prefixes = "B\0k\0M\0G\0T\0P\0E";
else
prefixes = "\0\0k\0M\0G\0T\0P\0E";
+ } else if (flags & HN_IEC_PREFIXES) {
+ divisor = 1024;
+ shift = 2;
+ if (flags & HN_B)
+ prefixes = "B\0\0\0Ki\0\0Mi\0\0Gi\0\0Ti\0\0Pi\0\0Ei";
+ else
+ prefixes = "\0\0\0\0Ki\0\0Mi\0\0Gi\0\0Ti\0\0Pi\0\0Ei";
} else {
- /*
-* binary multiplies
-* XXX IEC 60027-2 recommends Ki, Mi, Gi...
-*/
divisor = 1024;
+ shift = 1;
if (flags & HN_B)
prefixes = "B\0K\0M\0G\0T\0P\0E";
else
prefixes = "\0\0K\0M\0G\0T\0P\0E";
}
-#defineSCALE2PREFIX(scale) (&prefixes[(scale) << 1])
+#defineSCALE2PREFIX(scale) (&prefixes[(scale) << shift])
maxscale = 7;
if (scale >= maxscale &&
@@ -102,6 +121,10 @@ humanize_number(char *buf, size_t len, int64_t quotient,
sep = " ";
baselen++;
}
+ if (flags & HN_IEC_PREFIXES) {
+ baselen ++;
+ len ++;
+ }
baselen += strlen(suffix);
/* Check if enough room for `x y' + suffix + `\0' */
diff --git a/lib/libutil/libutil.h b/lib/libutil/libutil.h
index 66104e9..295a8d3 100644
--- a/lib/libutil/libutil.h
+++ b/lib/libutil/libutil.h
@@ -220,6 +220,7 @@ __END_DECLS
#define HN_NOSPACE 0x02
#define HN_B 0x04
#define HN_DIVISOR_10000x08
+#define HN_IEC_PREFIXES0x0f
#define HN_GETSCALE0x10
#define HN_AUTOSCALE 0x20
___
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] About the idea: Unicode support in vi
On Thu, Mar 24, 2011 at 5:17 PM, Johan van Selst wrote: > Zhihao Yuan wrote: >> 2. nvi does not use iconv, nvi-m17n only supports limited non-Unicode >> mbyte encodings, nvi-devel has too many problems. So we don't have a >> nvi which comes with fully mbyte enconding support; > > Could you please eleborate on the nvi-devel problems? I'm the current > maintainer of this port, and as far as I know it's fully functional. > nvi-devel does have proper UTF-8 support via libiconv. It is based on > the nvi version we currently have in base and much of the code base is > still identical. > > > Johan > 1. It does not support non-Unicode encodings. Actually, these encodings are mainstream in multi-byte encodings world. A proper iconv-awared implementation should be able to handle all of the encodings in `iconv -l`; 2. It depends on DB3/4. We won't accept DB3/4 in base system and we won't accept nvi-devel. 3. It's not 100% compatible with nvi 1.79. -- Zhihao Yuan The best way to predict the future is to invent it. ___ 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"
Switching to [KMGTPE]i prefixes?
hi there, i hacked up humanized_number(3) a bit in order to produce the following df(1) output: otaku% df -hi; df -Hi FilesystemSizeUsed Avail Capacity iused ifree %iused Mounted on /dev/ada0p3 217Gi 430Mi 200Gi 0%6.2k 29M0% / devfs1.0Ki 1.0Ki 0B 100% 0 0 100% /dev /dev/ufs/varfs 2Gi 286Mi 1.5Gi16% 27k 254k 10% /var /dev/ufs/usrfs 890Gi 758Gi60Gi93%1.0M 119M1% /usr linprocfs4.0Ki 4.0Ki 0B 100% 1 0 100% /usr/compat/linux/proc linsysfs 4.0Ki 4.0Ki 0B 100% 1 0 100% /usr/compat/linux/sys devfs1.0Ki 1.0Ki 0B 100% 0 0 100% /usr/compat/linux/dev linprocfs4.0Ki 4.0Ki 0B 100% 1 0 100% /usr/local/gentoo-stage3/proc linsysfs 4.0Ki 4.0Ki 0B 100% 1 0 100% /usr/local/gentoo-stage3/sys devfs1.0Ki 1.0Ki 0B 100% 0 0 100% /usr/local/gentoo-stage3/dev tmpfs2.0Gi 1.3Mi 2Gi 0% 21 524k0% /tmp /dev/cd0 4.2Gi 4.2Gi 0B 100% 0 0 100% /media/dvd FilesystemSizeUsed Avail Capacity iused ifree %iused Mounted on /dev/ada0p3 233G451M214G 0%6.2k 29M0% / devfs 1.0k1.0k 0B 100% 0 0 100% /dev /dev/ufs/varfs2.1G300M1.6G16% 27k 254k 10% /var /dev/ufs/usrfs956G814G 65G93%1.0M 119M1% /usr linprocfs 4.1k4.1k 0B 100% 1 0 100% /usr/compat/linux/proc linsysfs 4.1k4.1k 0B 100% 1 0 100% /usr/compat/linux/sys devfs 1.0k1.0k 0B 100% 0 0 100% /usr/compat/linux/dev linprocfs 4.1k4.1k 0B 100% 1 0 100% /usr/local/gentoo-stage3/proc linsysfs 4.1k4.1k 0B 100% 1 0 100% /usr/local/gentoo-stage3/sys devfs 1.0k1.0k 0B 100% 0 0 100% /usr/local/gentoo-stage3/dev tmpfs 2.1G1.3M2.1G 0% 21 524k0% /tmp /dev/cd0 4.5G4.5G 0B 100% 0 0 100% /media/dvd any thoughts whether this is something freebsd might benefit from or has it been decided that the current notion of prefixes mustn't be changed. cheers. alex -- a13x ___ 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] About the idea: Unicode support in vi
Zhihao Yuan wrote: > 2. nvi does not use iconv, nvi-m17n only supports limited non-Unicode > mbyte encodings, nvi-devel has too many problems. So we don't have a > nvi which comes with fully mbyte enconding support; Could you please eleborate on the nvi-devel problems? I'm the current maintainer of this port, and as far as I know it's fully functional. nvi-devel does have proper UTF-8 support via libiconv. It is based on the nvi version we currently have in base and much of the code base is still identical. Johan pgpEar3ZsAfUZ.pgp Description: PGP signature
Re: [GSoC] About the idea: Unicode support in vi
On Thu, Mar 24, 2011 at 5:07 PM, Julian H. Stacey wrote: > Zhihao Yuan wrote: > >> ed seems works, but it's not either vi or ex. >> I'm not typically like ee... I sill wondering why we kept it in base >> system. It does not work when termcap is not correct, so I still need >> to use ed in such a case. Same thing happens to ex-vi. > > History: > ee was added long ago by emacs afficionado jkh@ for the > sys installer eg /etc/inetd.conf > Small vi clones in source were available then too, on DOS 3.2 & Minix, > One was called Stevie, I can't remember the others. > > Replacing ee with a mini vi clone would be a return to Unix. > One would need to co-ordinate on O-O-Ok... Let emacs guys do emacs stuff. I need to go looking for a possible mentor on nvi... > > Cheers, > Julian > -- > Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com > Mail plain text; Not quoted-printable, Not HTML, Not base 64. > Reply below text sections not at top, to avoid breaking cumulative context. > -- Zhihao Yuan The best way to predict the future is to invent it. ___ 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] About the idea: Unicode support in vi
Zhihao Yuan wrote: > ed seems works, but it's not either vi or ex. > I'm not typically like ee... I sill wondering why we kept it in base > system. It does not work when termcap is not correct, so I still need > to use ed in such a case. Same thing happens to ex-vi. History: ee was added long ago by emacs afficionado jkh@ for the sys installer eg /etc/inetd.conf Small vi clones in source were available then too, on DOS 3.2 & Minix, One was called Stevie, I can't remember the others. Replacing ee with a mini vi clone would be a return to Unix. One would need to co-ordinate on Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, Not HTML, Not base 64. Reply below text sections not at top, to avoid breaking cumulative context. ___ 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"
GSoC
Hello. 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. ___ 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] About the idea: Unicode support in vi
On Thu, Mar 24, 2011 at 06:49:24AM -0500, Zhihao Yuan wrote: > On Thu, Mar 24, 2011 at 6:11 AM, Bernd Walter wrote: > > > > Let clean up the my points: > 1. ex-vi is POSIX vi compatible, and it supports mbyte encodings. But > there are lots of work need to be done if we want to use it to replace > the current nvi in the base system; > 2. nvi does not use iconv, nvi-m17n only supports limited non-Unicode > mbyte encodings, nvi-devel has too many problems. So we don't have a > nvi which comes with fully mbyte enconding support; > 3. Since other textproc tools, even include ed, support mbyte > encodings, we do need a improved nvi; > 4. Maybe compared with other kernel related GSoC proposals, this one > seems to be easier. But on the other hand, the goal is useful, and the > scale of the goal gives it more chance to become really useful. > > It that reasonable? > > -- > Zhihao Yuan > The best way to predict the future is to invent it. it makes sense to upgrade nvi rather that ex-vi ... for reasons prev'ly mentioned. talking about space/memory and even processor speed seems like a non-issue. i would like to be able to be editing a file with vim [[ for WHATEVER reason ]] and pick up or resume editing the same file with nvi. Of course there are dozens of alley-ways and twists and turns we all can get into is arguing this-and-that about the fine-grained details. It boils down to an issue of usefulness-- as i see it. be nice to have a "feature for feature, bug for bug" clone of vi that nvi used to claim to be. again: have nvi and vim be interchangable. oh: and then give the new nvi to the linux guys and let then deal with any port or build issues. > -- 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"
kgdb patches for newer versions of gdb
At work we cross-compile several kld modules. They just upgraded to gcc 4.5, but gdb 6.X is not compatible with the debug symbols produced by gcc 4.5. Has anybody ever tried merging kgdb into a newer gdb version? Anybody have patches that they can share? ___ 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"
[GSoc] Timeconter Performance Improvements
Hi, Thanks for your replay. That is just my self-introduction:) I want to borrow the shared memory idea from KVM, I am not want to port a whole KVM:) But for this project, there are some basic problems. As I know, tsc counter is CPU specific. If the process running on a multi-core platform, we must consider switching problem. The one way, we can let the kernel to take of this. When switching to another CPU, the kernel will reset the shared memory according to the new CPU. The second way, we can use CPUID instruction to get the info of current CPU, which can be executed in user mode ether. At the same time, the kernel maintains shared memory for each CPU. When invoke gettimeofday, the function will calculate precise time with current CPU's shared memory. I don't know which is better? Could I need to deal other problems? Jing. ___ 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: Timecounter Project (GSoc2011)
On 24/03/2011 14:11, Zhihao Yuan wrote: Well, it depends on the decision of core team. AFAIC, to make the KVM to be committed is very hard, especially for a GSoC project. Ah, please read what I'm saying: finish, not commit. But... I think the thread is not talking about the KVM itself... FUSE works. It's in the ports, as well as many file systems. No, it doesn't work. It crashes. Google will show you many bug reports, including mine. ___ 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: Timecounter Project (GSoc2011)
On Thu, Mar 24, 2011 at 7:27 AM, Ivan Voras wrote: > On 24/03/2011 12:21, Zhihao Yuan wrote: >> >> On Thu, Mar 24, 2011 at 5:39 AM, Ivan Voras wrote: >>> >>> On 24/03/2011 10:00, Jing Huang wrote: Hi Everyone, I am a student of Peking University in China. I am interest in the FreeBSD project of "Timecounter Performance Improvements". I am familiar with Linux kernel and virtualization systems, like KVM and Xen. I have maintained the Linux Server for my College for last whole year. Recently, I learned a lot about KVM and assigned VMs to students who need them. I also have experience of install and config FreeBSD system. >>> >>> Offtopic for your specific requests, but if you or these students would >>> like >>> to finish porting KVM to FreeBSD, that would also be a great GSoC >>> project! >>> >> >> Linux KVM was ported to FreeBSD before: >> http://retis.sssup.it/~fabio/freebsd/lkvm/ >> >> But their code are not clean, and the implementation only support >> FreeBSD 6/7 (due to the changes to the USB stack). Since there may be >> another big project to clean up their code, FreeBSD dropped that GSoC >> result. > > Yes, that is why I suggested finishing the port :) There is enough work in > finishing the KVM port that it can be a new GSoC project. > > (also, finishing FUSE...) > > ___ > 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" > Well, it depends on the decision of core team. AFAIC, to make the KVM to be committed is very hard, especially for a GSoC project. But... I think the thread is not talking about the KVM itself... FUSE works. It's in the ports, as well as many file systems. -- Zhihao Yuan The best way to predict the future is to invent it. ___ 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: Timecounter Project (GSoc2011)
On 24/03/2011 12:21, Zhihao Yuan wrote: On Thu, Mar 24, 2011 at 5:39 AM, Ivan Voras wrote: On 24/03/2011 10:00, Jing Huang wrote: Hi Everyone, I am a student of Peking University in China. I am interest in the FreeBSD project of "Timecounter Performance Improvements". I am familiar with Linux kernel and virtualization systems, like KVM and Xen. I have maintained the Linux Server for my College for last whole year. Recently, I learned a lot about KVM and assigned VMs to students who need them. I also have experience of install and config FreeBSD system. Offtopic for your specific requests, but if you or these students would like to finish porting KVM to FreeBSD, that would also be a great GSoC project! Linux KVM was ported to FreeBSD before: http://retis.sssup.it/~fabio/freebsd/lkvm/ But their code are not clean, and the implementation only support FreeBSD 6/7 (due to the changes to the USB stack). Since there may be another big project to clean up their code, FreeBSD dropped that GSoC result. Yes, that is why I suggested finishing the port :) There is enough work in finishing the KVM port that it can be a new GSoC project. (also, finishing FUSE...) ___ 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] About the idea: Unicode support in vi
On Thu, Mar 24, 2011 at 6:11 AM, Bernd Walter wrote: > On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote: >> On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe wrote: >> > Hi, >> > >> > On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan wrote: >> >> Among *all* the GNU/Linux distributions I used, they include a vim >> >> compiled in tiny mode (ln -s it to vi), which doubles the size of nvi, >> >> in their base systems. A vim.tiny contains much more features compared >> >> with nvi, but it's not compatible with POSIX vi. >> >> >> > Let's compare the comparable, I don't really care if PCbsd ship vim as >> > its default, but FreeBSD as the base is not only aimed at desktop >> > specifically. So you should take into account that I may want to run >> > FreeBSD on an adm5120 board with 32MB of RAM, without having a text >> > editor consuming too much disk-space/ram. >> > >> > - Arnaud >> > >> >> If you really want to use vi in a 32MB mem environment, the ex-vi may >> make sense. It consumes 1600KB memory while nvi consumes 2000KB. Note >> that the ee editor uses same amount memory as ex-vi. > > If you really want to save memory - RAM and filesystem - in such a reduced > way, then you need something else. > /bin/sh without history, reduced termcap, sparsed rc.d and you should > also consider static linked crunchgen binaries. > This has nothing to do with any other typical installation. > Also Linux doesn't do this - there are Linux distributions using bloated > featured binaries and there are tiny distributions with low footprint > tools such as busybox. > >> So basically, if no one disagree that we can drop the infinite undo, >> multiple buffer, multiple window and some other potential missing >> features, we can replace the nvi in the base system with ex-vi. > > Of course people will disagree. > The thread is about adding unicode support this means they want to stay > with the features of our current editor. > I like the window feature of nvi, but I don't really need it for the > system editor, but having Unicode support would be a big win and multiple > undo is very valueable for a system editor. > Of course this isn't one of the must have features on a memory constrained > box, but only because you have a higher pressure. > It is true that you can easily add your favourite editor from ports, > but it is also true that I often get phone calls to help them with their > systems and in this case you want a useable editor, which is just there > for sure. > If a machine isn't online, e.g. because of a trashed filesystem you can't > install a random editor and must live with what's there to fix the > situation. > And yes - I also often use ed in many crashed situations, because it > is easier to fix e.g. an fstab with ed and reboot than to setup your > terminal environment. > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > Let clean up the my points: 1. ex-vi is POSIX vi compatible, and it supports mbyte encodings. But there are lots of work need to be done if we want to use it to replace the current nvi in the base system; 2. nvi does not use iconv, nvi-m17n only supports limited non-Unicode mbyte encodings, nvi-devel has too many problems. So we don't have a nvi which comes with fully mbyte enconding support; 3. Since other textproc tools, even include ed, support mbyte encodings, we do need a improved nvi; 4. Maybe compared with other kernel related GSoC proposals, this one seems to be easier. But on the other hand, the goal is useful, and the scale of the goal gives it more chance to become really useful. It that reasonable? -- Zhihao Yuan The best way to predict the future is to invent it. ___ 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: Timecounter Project (GSoc2011)
On Thu, Mar 24, 2011 at 5:39 AM, Ivan Voras wrote: > On 24/03/2011 10:00, Jing Huang wrote: >> >> Hi Everyone, >> >> I am a student of Peking University in China. I am interest >> in the FreeBSD project of "Timecounter Performance Improvements". >> >> I am familiar with Linux kernel and virtualization systems, >> like KVM and Xen. I have maintained the Linux Server for my College >> for last whole year. Recently, I learned a lot about KVM and assigned >> VMs to students who need them. I also have experience of install and >> config FreeBSD system. > > Offtopic for your specific requests, but if you or these students would like > to finish porting KVM to FreeBSD, that would also be a great GSoC project! > Linux KVM was ported to FreeBSD before: http://retis.sssup.it/~fabio/freebsd/lkvm/ But their code are not clean, and the implementation only support FreeBSD 6/7 (due to the changes to the USB stack). Since there may be another big project to clean up their code, FreeBSD dropped that GSoC result. > > ___ > 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" > -- Zhihao Yuan The best way to predict the future is to invent it. ___ 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] About the idea: Unicode support in vi
On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote: > On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe wrote: > > Hi, > > > > On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan wrote: > >> Among *all* the GNU/Linux distributions I used, they include a vim > >> compiled in tiny mode (ln -s it to vi), which doubles the size of nvi, > >> in their base systems. A vim.tiny contains much more features compared > >> with nvi, but it's not compatible with POSIX vi. > >> > > Let's compare the comparable, I don't really care if PCbsd ship vim as > > its default, but FreeBSD as the base is not only aimed at desktop > > specifically. So you should take into account that I may want to run > > FreeBSD on an adm5120 board with 32MB of RAM, without having a text > > editor consuming too much disk-space/ram. > > > > - Arnaud > > > > If you really want to use vi in a 32MB mem environment, the ex-vi may > make sense. It consumes 1600KB memory while nvi consumes 2000KB. Note > that the ee editor uses same amount memory as ex-vi. If you really want to save memory - RAM and filesystem - in such a reduced way, then you need something else. /bin/sh without history, reduced termcap, sparsed rc.d and you should also consider static linked crunchgen binaries. This has nothing to do with any other typical installation. Also Linux doesn't do this - there are Linux distributions using bloated featured binaries and there are tiny distributions with low footprint tools such as busybox. > So basically, if no one disagree that we can drop the infinite undo, > multiple buffer, multiple window and some other potential missing > features, we can replace the nvi in the base system with ex-vi. Of course people will disagree. The thread is about adding unicode support this means they want to stay with the features of our current editor. I like the window feature of nvi, but I don't really need it for the system editor, but having Unicode support would be a big win and multiple undo is very valueable for a system editor. Of course this isn't one of the must have features on a memory constrained box, but only because you have a higher pressure. It is true that you can easily add your favourite editor from ports, but it is also true that I often get phone calls to help them with their systems and in this case you want a useable editor, which is just there for sure. If a machine isn't online, e.g. because of a trashed filesystem you can't install a random editor and must live with what's there to fix the situation. And yes - I also often use ed in many crashed situations, because it is easier to fix e.g. an fstab with ed and reboot than to setup your terminal environment. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: Timecounter Project (GSoc2011)
On 24/03/2011 10:00, Jing Huang wrote: Hi Everyone, I am a student of Peking University in China. I am interest in the FreeBSD project of "Timecounter Performance Improvements". I am familiar with Linux kernel and virtualization systems, like KVM and Xen. I have maintained the Linux Server for my College for last whole year. Recently, I learned a lot about KVM and assigned VMs to students who need them. I also have experience of install and config FreeBSD system. Offtopic for your specific requests, but if you or these students would like to finish porting KVM to FreeBSD, that would also be a great GSoC project! ___ 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 BOOTWAIT still used? (Was: kernel memory checks on boot vs. boot time)
Pan Tsu wrote:
> Oliver Fromme writes:
>
> [...]
> > To be honest, I don't think that loader takes so much time.
> > When you set autoboot_delay="-1" and beastie_disable="YES",
> > the time spent in loader is negligible. (I'm assuming that
> > you also set BOOTWAIT=0 in make.conf, so boot2 doesn't wait
> > for a keypress either. I think the default is to wait 3
> > seconds.)
>
> Is BOOTWAIT still used? A quick grep in sys/boot shows nothing.
You're right, unfortunately.
boot0 still has a configurable timeout which is 10 seconds
by default. It can be configured via BOOT_BOOT0_TICKS in
make conf (default is 182 because the BIOS ticks run at
18.2 Hz).
However, the 3 seconds delay is hardcoded in boot2.c:
if (!keyhit(3*SECOND)) {
load();
I have no idea why it isn't configurable anymore. Is there
a reason for that? I'll write a patch unless anybody
objects.
> Digging history, BOOTWAIT never made its way from sys/i386/boot
> to sys/boot/i386 and was removed in r58284 around 11y ago.
11 years ago?!? Time to either update the documentation
or -- better yet -- bring the feature back, I would say.
Being able to shave 3 seconds off the boot time of a HTPC
(among others) is not negligible.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
"I have stopped reading Stephen King novels.
Now I just read C code instead."
-- Richard A. O'Keefe
___
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"
Timecounter Project (GSoc2011)
Hi Everyone, I am a student of Peking University in China. I am interest in the FreeBSD project of "Timecounter Performance Improvements". I am familiar with Linux kernel and virtualization systems, like KVM and Xen. I have maintained the Linux Server for my College for last whole year. Recently, I learned a lot about KVM and assigned VMs to students who need them. I also have experience of install and config FreeBSD system. In this scenario, I plan to use both tsc and shared memory to calculate precise time in user mode. The shared memory includes system_time, tsc_system_time and factor_tsc-system_time. a) system_time is the current time since the system boots, and it will be updated by time interrupt handling function. b) tsc_system_time is the tsc value when system_time update, and it is used to calculate rough delta. c) factor_tsc-system_time records the correspondence between tsc and time. It is used to calculate precise delta. When the process invokes gettimeofday, our mechanism will calculate time like: system_time+ ( factor_tsc-system_time(instant_rdtsc - tsc_system_time ) ). We see factor_tsc-system_time as a computing method here. I could refer to the relative implementation in KVM or Xen virtual machine. The real problem is that tsc counter is CPU sensitive. Our process will get wrong tsc value when switching to another CPU. I plan to force the FreeBSD kernel to update shared memory when monitoring context switch event. Alternatively, we can build NR_CPUS shared memories, and every CPU has one. Hmm.. how to recognize which CPU we are using in user mode? We also consider the CPU frequency, because tsc counter is related to it. When kernel changes CPU frequency, the shared memory should be update subsequently. Would some one give me some suggestions? Looking forward to your reply. yours sincerely. Jing ___ 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 BOOTWAIT still used? (Was: kernel memory checks on boot vs. boot time)
Oliver Fromme writes: [...] > To be honest, I don't think that loader takes so much time. > When you set autoboot_delay="-1" and beastie_disable="YES", > the time spent in loader is negligible. (I'm assuming that > you also set BOOTWAIT=0 in make.conf, so boot2 doesn't wait > for a keypress either. I think the default is to wait 3 > seconds.) Is BOOTWAIT still used? A quick grep in sys/boot shows nothing. Digging history, BOOTWAIT never made its way from sys/i386/boot to sys/boot/i386 and was removed in r58284 around 11y ago. And more recently it disappeared from pc98, see r201342. %% Index: share/examples/etc/make.conf === --- share/examples/etc/make.conf(revision 219947) +++ share/examples/etc/make.conf(working copy) @@ -138,14 +138,6 @@ #PRINTERDEVICE=ps # # -# How long to wait for a console keypress before booting the default kernel. -# This value is approximately in milliseconds. Keypresses are accepted by the -# BIOS before booting from disk, making it possible to give custom boot -# parameters even when this is set to 0. -# -#BOOTWAIT=0 -#BOOTWAIT=3 -# # By default, the system will always use the keyboard/video card as system # console. However, the boot blocks may be dynamically configured to use a # serial port in addition to or instead of the keyboard/video console. Index: share/man/man5/make.conf.5 === --- share/man/man5/make.conf.5 (revision 219947) +++ share/man/man5/make.conf.5 (working copy) @@ -330,14 +330,6 @@ This defaults to The following list provides a name and short description for variables that are only used doing a kernel build: .Bl -tag -width Ar -.It Va BOOTWAIT -.Pq Vt int -Controls the amount of time the kernel waits for a console keypress -before booting the default kernel. -The value is approximately milliseconds. -Keypresses are accepted by the BIOS before booting from disk, -making it possible to give custom boot parameters even when this is -set to 0. .It Va COPTFLAGS .Pq Vt str Controls the compiler settings when building the %% ___ 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"
