Re: Switching to [KMGTPE]i prefixes?

2011-03-24 Thread Warner Losh
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

Re: Switching to [KMGTPE]i prefixes?

2011-03-24 Thread Bruce Cran
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. -- Bruc

Re: Switching to [KMGTPE]i prefixes?

2011-03-24 Thread Alexander Best
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.

Re: Switching to [KMGTPE]i prefixes?

2011-03-24 Thread Alexander Best
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

Re: [GSoC] About the idea: Unicode support in vi

2011-03-24 Thread Zhihao Yuan
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

Switching to [KMGTPE]i prefixes?

2011-03-24 Thread Alexander Best
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

Re: [GSoC] About the idea: Unicode support in vi

2011-03-24 Thread Johan van Selst
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 o

Re: [GSoC] About the idea: Unicode support in vi

2011-03-24 Thread Zhihao Yuan
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

Re: [GSoC] About the idea: Unicode support in vi

2011-03-24 Thread Julian H. Stacey
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

GSoC

2011-03-24 Thread Dudinskyi Olexandr
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 dev

Re: [GSoC] About the idea: Unicode support in vi

2011-03-24 Thread Gary Kline
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

kgdb patches for newer versions of gdb

2011-03-24 Thread Ryan Stone
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? _

[GSoc] Timeconter Performance Improvements

2011-03-24 Thread Jing Huang
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 platfor

Re: Timecounter Project (GSoc2011)

2011-03-24 Thread Ivan Voras
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... FU

Re: Timecounter Project (GSoc2011)

2011-03-24 Thread Zhihao Yuan
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 interes

Re: Timecounter Project (GSoc2011)

2011-03-24 Thread Ivan Voras
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

Re: [GSoC] About the idea: Unicode support in vi

2011-03-24 Thread Zhihao Yuan
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 use

Re: Timecounter Project (GSoc2011)

2011-03-24 Thread Zhihao Yuan
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 ker

Re: [GSoC] About the idea: Unicode support in vi

2011-03-24 Thread Bernd Walter
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

Re: Timecounter Project (GSoc2011)

2011-03-24 Thread Ivan Voras
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 t

Re: Is BOOTWAIT still used? (Was: kernel memory checks on boot vs. boot time)

2011-03-24 Thread Oliver Fromme
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 boo

Timecounter Project (GSoc2011)

2011-03-24 Thread Jing Huang
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 who

Is BOOTWAIT still used? (Was: kernel memory checks on boot vs. boot time)

2011-03-24 Thread Pan Tsu
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 eith