Re: [GSoC] About the idea: Unicode support in vi
Zhihao Yuan wrote: > > 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. > 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. Thank you for explaining. Indeed, all valid points and I fully agree that nvi-devel is not fit for inclusion in base as it is. In fact, the nvi from base is probably a better starting point (than nvi-devel) to create an editor that is fully compatible with nvi 1.79 and supports all multi-byte encodings. And when you, or someone, else creates such an editor, I will be pleased to remove the obsoleted port of nvi-devel. Johan pgpdrm84mqX2I.pgp Description: PGP signature
Re: Switching to [KMGTPE]i prefixes?
On Fri Mar 25 11, Bruce Cran wrote: > 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. hmmm...i'm wondering why they do that. there's no reason for that, because 1 bytes is 8 bit no matter if you use a power of one or a power of ten. cheers. alex > > -- > Bruce Cran -- 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: Switching to [KMGTPE]i prefixes?
On Thu Mar 24 11, Warner Losh wrote: > The new flag is '0x0f' but it should be '0x40' since that's a bit field... thanks for the hint. i've updated that particular line in libutil.h. > > 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" -- 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"
[ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
Hi all, miwi@ launched the new thing called Experimental Call For Testing, it's our turn :) Julien Laffaye (jlaffaye@) and I, helped by Philippe Pepiot (huge contributor) have been working since the end of the last GSoC on a rewrite of pkg_install. pkgng is a binary package manager written from scratch for FreeBSD. After a long period of technology testing, (json, tinycdb, bdb, etc) and we now have achieved to implement the basic functionnality. We would greatly approciate to have some feedback, wider testing, patching, documenting etc, before implementing the higher level features. pkgng is built on top of a new libpkg, which allow to deal with the database of installed packages, to deal with remote repositories, manage packages: creation, installation gathering informations, registering new ports. features supported are or will be : - smooth integration with bsd.port.mk (including bsd.pkg.mk line 2486) which allow to have a bsd.port.mk which deal with both pkg_install and pkgng. (done in alpha) - the register command can analyse elf files when registering a new port to discover forgotten dependencies if necessary. (done in alpha using libelf) - the register command has two mode available : when dealing with old fashion ports it just registers the package, in new mode it does everything that would have been done by pkg add when installing the package : should display messages, execute post-install, execute @exec etc. (old fashion done in the alpha) - pkg add supports two mode : the old fashion one (no real upgrade support) and new one: upgrade scripts supported. (old fashion in the alpha) - new scripts supported +PREINSTALL +POSTINSTALL, +PREDEINSTALL, +POSTDEINSTALL, +PREUPGRADE, +POSTUPGRADE as well as the old fashion scripts : +INSTALL +DEINSTALL +UPGRADE (all supported *UPGRADES aren't supported in the alpha) - new +MANIFEST (plist-like format) with new metadatas : options, arch, os version, etc. (done in the alpha) - pkgng supports checking arch of the package which means that users won't be able to install sparc64 binary package into amd64 machines. (not done yet) - a special architecture "all" allows to specify when a package can be used on every architecture. (not done yet) - @dirrm and @dirrmtry are now deprecated, pkgng can discover itself which directory has to be removed. (done in the alpha but needs love :)) - new repository (apt-like feature) (only the repository generation is done) - real support for reverse dependency (no ugly +REQUIRED_BY) (done in the alpha) - test unit (libcheck) on libpkg. (done in the alpha needs some more love) - many more In term of technology we decided to use a sqlite3 database, and to prevent potential trolling, sqlite3 is used in it's amalgamation form which means it is incorporated in the code sources (as recommanded by sqlite developpers like a statically linked library) on build we only activate the features we need in sqlite. The alpha release come with an experimental tool "pkg2ng" to convert an existing package database to the new pkgng database format. So one can test pkgng without rebuild all its packages. One of the thing we are thinking about pkgng is to perhaps be able to provide it only as a ports (with simple script in base to boostrap/install it). That would allow pkgng to live with the ports to be able to easily integrate new features without having to support very old version of pkgng. design: pkgng is composed of : - a clean library "libpkg" that does all the work - a modern cli frontend (pkg) which accept subcommands, basically type pkg add, pkg info, pkg create etc. a dedicated subcommand exists for ports: pkg register which goal is to only supported adding to the database what is already installed. more informations can be found here: http://git.etoilebsd.net/pkgng/tree/docs/GOALS, http://git.etoilebsd.net/pkgng/tree/README http://git.etoilebsd.net/pkgng/tree/docs/TODO To download the alpha: http://git.etoilebsd.net/pkgng/snapshot/pkgng-0.1-alpha1.tar.gz Build it with debugging information: make DEBUG_FLAGS="-g -O0 -DDEBUG" Developpement site: http://git.etoilebsd.net/pkgng/ IRC chan: #pkgng@freenode Beware that pkgng is in alpha states, it can kill kittens and eat puppies, and for sure it will do it so now you are warned. regards, bapt, pgpbgmBRFdsib.pgp Description: PGP signature
Re: [GSoc] Timeconter Performance Improvements
On 2011-Mar-24 17:00:02 +0800, Jing Huang wrote: > 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. This sounds like a reasonable approach to me. Note that once we implement a shared page, there is probably a variety of other information we could usefully place on that page. SunOS 4.x included a page of shared memory per CPU. This was mapped as an array (indexed by CPU number) at one address and the page reflecting the current CPU was additionally mapped at another fixed address. This allowed a process to both refer to data on its CPU as well any CPU on the system. > 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. Two issues with this, particularly on x86 without invariant TSC: - looking up the current CPU frequency may not be a cheap operation - the reported CPU frequency appears to be just an approximate value, rather than the actual TSC frequency. On 2011-Mar-24 21:34:35 +0800, Jing Huang wrote: >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. I'm not sure what the cost of managing this page mapping will be. >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. This approach suffers from a race condition between the CPUID instruction and accessing the appropriate shared page - there is the potential for an interrupt causing the process to be switched to a different CPU, resulting in an incorrect page being accessed. -- Peter Jeremy pgpHImAnkRcSI.pgp Description: PGP signature
Re: dtrace sdt problem: my fault or a generic problem (SYSINIT not working as expected for modules)?
on 25/03/2011 11:52 Alexander Leidinger said the following: > As I read it, it looks a little bit like the SYSINIT of the SDT probes didn't > work as expected for my new probes (does this work in modules? fxr.watson.org > AFAICS only lists SDT probes in kernel-code, not in module-code), a hit with > the > clue-bat is welcome. My reading of the code is that all modules with SDT proivders/probes should be loaded before sdt module itself. SYSINIT in your module(s) works as expect, but dtrace_register() is not called on your SDT provider. See sys/cddl/dev/sdt/sdt.c for details: sdt_modevent -> sdt_load -> sdt_provider_listall(sdt_provider_reg_callback) -> dtrace_register. I am not saying that this behavior is correct/desired, just that this is what we have now. -- 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
Dudinskyi Olexandr wrote: 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" hi im lazaax i dont study but i like unix system and do some things i have a proyect called sys7server i like to participate on gsoc and tell about sys7 and sys7server proyects .. ___ 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"
dtrace sdt problem: my fault or a generic problem (SYSINIT not working as expected for modules)?
Hi,
I'm in the process of adding some SDT probes to the linuxulator.
Unfortunately I get a kernel panic while doing a "dtrace -l -P
linuxulator". What I see in kgdb puzzles me. Maybe someone can help out?
The id of the provider is 0x0, I would expect this is a little
problem. Debugging session follows with some discussion inline and
afterwards.
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x48
fault code = supervisor read, page not present
instruction pointer = 0x20:0x80db03db
stack pointer = 0x28:0xafb4d7f8
frame pointer = 0x28:0xafb4d83c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1415 (initial thread)
trap number = 12
panic: page fault
Uptime: 10m4s
#5 0x8071e9c6 in trap (frame=0xafb4d7b8) at ../../../i386/i386/trap.c:553
#6 0x8070aa4c in calltrap () at ../../../i386/i386/exception.s:168
#7 0x80db03db in dtrace_probe_lookup (prid=0, mod=0xafb4d8e0 "emul",
func=0xafb4d8a0 "linux_schedtail", name=0xafb4d860 "return")
at
/usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:7807
#8 0x80ee0955 in sdt_probe_callback (probe=0x859daca0, arg=0x0)
at /usr/src/sys/modules/dtrace/sdt/../../../cddl/dev/sdt/sdt.c:131
(kgdb) up 7
During symbol reading, Incomplete CFI data; unspecified registers at
0x80560633.
#7 0x80db03db in dtrace_probe_lookup (prid=0x0, mod=0xafb4d8e0
"emul", func=0xafb4d8a0 "linux_schedtail",
name=0xafb4d860 "return")
at
/usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:7807
7807pkey.dtpk_mmatch = mod ? &dtrace_match_string :
&dtrace_match_nul;
prid is zero...?
(kgdb) list
7802int match;
7803
7804pkey.dtpk_prov = ((dtrace_provider_t *)prid)->dtpv_name;
7805pkey.dtpk_pmatch = &dtrace_match_string;
7806pkey.dtpk_mod = mod;
7807pkey.dtpk_mmatch = mod ? &dtrace_match_string :
&dtrace_match_nul;
7808pkey.dtpk_func = func;
7809pkey.dtpk_fmatch = func ? &dtrace_match_string :
&dtrace_match_nul;
7810pkey.dtpk_name = name;
7811pkey.dtpk_nmatch = name ? &dtrace_match_string :
&dtrace_match_nul;
(kgdb) print pkey
$1 = {
dtpk_prov = 0x1e58 ,
dtpk_pmatch = 0xafb4d83c,
dtpk_mod = 0x80db1143 "\213E203034[^_]\220 ,S200d\213\025",
dtpk_mmatch = 0x80ed531c ,
dtpk_func = 0x80dc68d8
"/usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c",
dtpk_fmatch = 0x1e58,
dtpk_name = 0x1e18 ,
dtpk_nmatch = 0x72e,
dtpk_id = 0x72f
}
(kgdb) print ((dtrace_provider_t *)prid)->dtpv_name
Cannot access memory at address 0x48
Ok, prid is NULL, so this is not a surprise, but why is it NULL?
(kgdb) print prid
$2 = 0x0
(kgdb) print mod
$3 = 0xafb4d8e0 "emul"
(kgdb) up 1
#8 0x80ee0955 in sdt_probe_callback (probe=0x859daca0, arg=0x0)
at /usr/src/sys/modules/dtrace/sdt/../../../cddl/dev/sdt/sdt.c:131
131 if (dtrace_probe_lookup(prov->id, mod, func, name) != 0)
(kgdb) list
126 */
127 strlcpy(mod, probe->mod, sizeof(mod));
128 strlcpy(func, probe->func, sizeof(func));
129 strlcpy(name, probe->name, sizeof(name));
130
131 if (dtrace_probe_lookup(prov->id, mod, func, name) != 0)
132 return (0);
133
134 (void) dtrace_probe_create(prov->id, probe->mod, probe->func,
135 probe->name, 0, probe);
(kgdb) print prov
$4 = (struct sdt_provider *) 0x859da520
(kgdb) print *prov
$5 = {
name = 0x859d719d "linuxulator",
prov_entry = {
tqe_next = 0x0,
tqe_prev = 0x807bbac4
},
probe_list = {
tqh_first = 0x859daca0,
tqh_last = 0x859e442c
},
id = 0x0
}
(kgdb) print probe
$6 = (struct sdt_probe *) 0x859daca0
(kgdb) print *probe
$7 = {
version = 0x34,
state = SDT_INIT,
prov = 0x859da520,
probe_entry = {
tqe_next = 0x859dac40,
tqe_prev = 0x859da52c
},
argtype_list = {
tqh_first = 0x0,
tqh_last = 0x859dacb4
},
mod = 0x859d7204 "emul",
func = 0x859d72af "linux_schedtail",
name = 0x859d721f "return",
id = 0x0,
n_args = 0x0
}
It looks suspicious to mee that the id is NULL. Here is what I do:
kernel with KDTRACE_HOOKS, makeoptions WITH_CTF=yes, DDB_CTF. The SDT
probes are in linux.ko which is loaded after the dtrace, cyclic, sdt,
profile, fbt, systrace and lockstat modules. My patches are at
http://www.Leidinger.net/FreeBSD/current-patches/linuxulator-dtrace.diff
linux_emul.c contains LIN_SDT_PROVIDER_DEFINE(LINUX_DTRACE); which is
just a mapping of SDT_PROVIDE_DEFINE. All other files contain the
corresponding DECLARE.
Actually the kernel crashed at another place which uses automatically
genera
Re: [GSoc] Timeconter Performance Improvements
On Thursday, March 24, 2011 9:34:35 am Jing Huang wrote: > 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? 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. You can easily export a copy of the current 'timehands' structure when the TSC is used as the timecounter and then just reimplement bintime() in userland. This assumes you use the TSC as the kernel's timecounter, but you really need to do that so that ntpd_adjtime() is taken into account, etc. That will give a very fast and very cheap timecounter. I believe we already have a shared page (it holds the signal trampoline now) for at least the x86 platform (probably some others as well). -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: dtrace sdt problem: my fault or a generic problem (SYSINIT not working as expected for modules)?
Quoting Andriy Gapon (from Fri, 25 Mar 2011 12:56:56 +0200): on 25/03/2011 11:52 Alexander Leidinger said the following: As I read it, it looks a little bit like the SYSINIT of the SDT probes didn't work as expected for my new probes (does this work in modules? fxr.watson.org AFAICS only lists SDT probes in kernel-code, not in module-code), a hit with the clue-bat is welcome. My reading of the code is that all modules with SDT proivders/probes should be loaded before sdt module itself. SYSINIT in your module(s) works as expect, but dtrace_register() is not called on your SDT provider. See sys/cddl/dev/sdt/sdt.c for details: sdt_modevent -> sdt_load -> sdt_provider_listall(sdt_provider_reg_callback) -> dtrace_register. So if I load linux.ko before sdt.ko, or if I unload sdt.ko and reload it, it should work? I'm going to try this after sending this mail. I am not saying that this behavior is correct/desired, just that this is what we have now. Is someone working on this? If not, what would be a solution for this? Adding a call (which one) to the modevent of the module which is using SDT probes? Can we prevent a kernel panic for this case (maybe detecting a NULL ID and skipping... or maybe even registering it)? Something to add to the ideas list as a GSoC entry, or is this too small/big? Bye, Alexander. -- One way to make your old car run better is to look up the price of a new model. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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 Fri, Mar 25, 2011 at 10:40:44AM +0100, Johan van Selst wrote: > Zhihao Yuan wrote: > > > 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. > > 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. > > Thank you for explaining. Indeed, all valid points and I fully agree > that nvi-devel is not fit for inclusion in base as it is. In fact, the > nvi from base is probably a better starting point (than nvi-devel) to > create an editor that is fully compatible with nvi 1.79 and supports all > multi-byte encodings. And when you, or someone, else creates such an > editor, I will be pleased to remove the obsoleted port of nvi-devel. Has anyone looked at the nvi work that has taken place in NetBSD in the last year or so? I think they've put in a bunch of wide character support. I'm not sure if their DB code relies on bdb newer than what is in libc or not. -Kurt ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
2011/3/25 Alexander Leidinger : > Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 > 11:11:11 +0100): > >> pkgng is a binary package manager written from scratch for FreeBSD. > > I didn't had a look at it, just some comments about some parts you > explained. > >> features supported are or will be : > >> - the register command can analyse elf files when registering a new port >> to >> discover forgotten dependencies if necessary. (done in alpha using libelf) > > This will probably fail if LD_LIBRARY_PATH is used, or if we are installing > linuxulator ports. > this isn't activated by default, and if activated is only intended to work on freebsd elf files. This is done to workaround some bugguy ports not to be used in production, pkg register shows in warning in that case so that user/maintainers are warned they have something to fix. >> >> - a special architecture "all" allows to specify when a package can be >> used >> on every architecture. (not done yet) > > What if a package is able to install on a subset, e.g. the linuxulator ports > are for amd64 and i386? > No clue for that at the moment but we are open to suggestions. > What about DB corruption/loss? Do you keep the /var/db/pkg//xxx > files even with pkgng and only use the DB as a way to speed up some work (so > the DB corruption just requires to run pkg2ng), or are you lost of the DB is > lost? > Nothing is done about DB corruption/loss, I am not sure we need to do something. Maybe. Currently a filesystem corruption/loss on /var/db/pkg would do the same. but it is sqlite so we can perhaps provide a way to get compressed dump so user can periodically backup their database. regards, Bapt ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Fri, Mar 25, 2011 at 2:38 PM, Alexander Leidinger wrote: > Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 > 15:14:52 +0100): > >> 2011/3/25 Alexander Leidinger : >>> >>> Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 >>> 11:11:11 +0100): >>> pkgng is a binary package manager written from scratch for FreeBSD. >>> >>> I didn't had a look at it, just some comments about some parts you >>> explained. >>> features supported are or will be : > - a special architecture "all" allows to specify when a package can be used on every architecture. (not done yet) >>> >>> What if a package is able to install on a subset, e.g. the linuxulator >>> ports >>> are for amd64 and i386? >>> >> >> No clue for that at the moment but we are open to suggestions. > > The suggestion is easy, allow a way to specify a set of valid architectures. That looks reasonable and easy to implement. > >>> What about DB corruption/loss? Do you keep the /var/db/pkg//xxx >>> files even with pkgng and only use the DB as a way to speed up some work >>> (so >>> the DB corruption just requires to run pkg2ng), or are you lost of the DB >>> is >>> lost? >>> >> >> Nothing is done about DB corruption/loss, I am not sure we need to do >> something. >> Maybe. > > I would say "for sure". Info: In Solaris 10 sqlite is used for the service > managenemt framework (SMF). It is possible that the DB is corrupt in some > bad situations. In this case you have to rebuild the DB (script provided, > been there, had to use it). If sqlite is properly used with transactions, it is very hard to corrupt the database. But if hardware lies to us and say that the data is on disk whereas it isnt... what can we do? Another potential problem is fsync(), but if it is broken on FreeBSD we want to fix it! BTW, the goal is to only have the database and not the flat files. If you are paranoid about power outage, use something like zfs snapshots... > >> Currently a filesystem corruption/loss on /var/db/pkg would do the same. > > Put a corruption of /var/db/pkg/xyz-1/+REQUIRED_BY would only affect a small > part, and this part could be even recovered from (pkgdb from portupgrade is > able to do it). With sqlite we have atomicity! And locks! > >> but it is sqlite so we can perhaps provide a way to get compressed >> dump so user can periodically backup their database. > > It needs to be automated. Maybe periodic daily... but maybe this is not > often enough after a day of a lot of changes (think about it this way: do > you want to lose a day of changes?). The current FS based DB is very robust, > partly because there is redundant data, pertly because losing a file just > means that the very limited subset of information is lost (and a reinstall > of one port will fix it). > > Bye, > Alexander. Regards, Julien ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On 2011-Mar-25, 15:03, Julien Laffaye wrote: > >>> What about DB corruption/loss? Do you keep the /var/db/pkg//xxx > >>> files even with pkgng and only use the DB as a way to speed up some work > >>> (so > >>> the DB corruption just requires to run pkg2ng), or are you lost of the DB > >>> is > >>> lost? > >>> > >> > >> Nothing is done about DB corruption/loss, I am not sure we need to do > >> something. > >> Maybe. > > > > I would say "for sure". Info: In Solaris 10 sqlite is used for the service > > managenemt framework (SMF). It is possible that the DB is corrupt in some > > bad situations. In this case you have to rebuild the DB (script provided, > > been there, had to use it). > > If sqlite is properly used with transactions, it is very hard to > corrupt the database. But if hardware lies to us and say that the data > is on disk whereas it isnt... what can we do? > Another potential problem is fsync(), but if it is broken on FreeBSD > we want to fix it! > > BTW, the goal is to only have the database and not the flat files. > If you are paranoid about power outage, use something like zfs snapshots... No need to look for strange scenarios, I'm surely going to sudo rm -f the file more sooner than later, so... maybe just save a copy? -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgplRCGE7qXwo.pgp Description: PGP signature
Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
2011/3/25 Pietro Cerutti : > On 2011-Mar-25, 15:03, Julien Laffaye wrote: >> >>> What about DB corruption/loss? Do you keep the /var/db/pkg//xxx >> >>> files even with pkgng and only use the DB as a way to speed up some work >> >>> (so >> >>> the DB corruption just requires to run pkg2ng), or are you lost of the DB >> >>> is >> >>> lost? >> >>> >> >> >> >> Nothing is done about DB corruption/loss, I am not sure we need to do >> >> something. >> >> Maybe. >> > >> > I would say "for sure". Info: In Solaris 10 sqlite is used for the service >> > managenemt framework (SMF). It is possible that the DB is corrupt in some >> > bad situations. In this case you have to rebuild the DB (script provided, >> > been there, had to use it). >> >> If sqlite is properly used with transactions, it is very hard to >> corrupt the database. But if hardware lies to us and say that the data >> is on disk whereas it isnt... what can we do? >> Another potential problem is fsync(), but if it is broken on FreeBSD >> we want to fix it! >> >> BTW, the goal is to only have the database and not the flat files. >> If you are paranoid about power outage, use something like zfs snapshots... > > No need to look for strange scenarios, I'm surely going to sudo rm -f the file > more sooner than later, so... maybe just save a copy? > > -- > Pietro Cerutti > The FreeBSD Project > g...@freebsd.org > > PGP Public Key: > http://gahr.ch/pgp > I think we can provide a periodic script activable by users (I let other decide if it has to be activated by default or not) that does a pkg backup /path/to/file/backup and xz it. because copying can be a huge. 40Mo for the database here, corresponding to 70Mo in the old format and to 600 packages. the dump xzed is only 3Mo regards, Bapt ___ 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: dtrace sdt problem: my fault or a generic problem (SYSINIT not working as expected for modules)?
Quoting Alexander Leidinger (from Fri, 25 Mar 2011 14:14:49 +0100): Quoting Andriy Gapon (from Fri, 25 Mar 2011 12:56:56 +0200): on 25/03/2011 11:52 Alexander Leidinger said the following: As I read it, it looks a little bit like the SYSINIT of the SDT probes didn't work as expected for my new probes (does this work in modules? fxr.watson.org AFAICS only lists SDT probes in kernel-code, not in module-code), a hit with the clue-bat is welcome. My reading of the code is that all modules with SDT proivders/probes should be loaded before sdt module itself. SYSINIT in your module(s) works as expect, but dtrace_register() is not called on your SDT provider. See sys/cddl/dev/sdt/sdt.c for details: sdt_modevent -> sdt_load -> sdt_provider_listall(sdt_provider_reg_callback) -> dtrace_register. So if I load linux.ko before sdt.ko, or if I unload sdt.ko and reload it, it should work? I'm going to try this after sending this mail. Unloading sdt.ko was a bad idea... currently I'm waiting the machine recovers from this rude action. It seems there are some modunload checks missing to prevent a kernel panic by unloading sdt.ko when it is not safe. Do we have a place where we can document the current state of afairs, or shall I just add something to the wiki pages (the unload problem to the DTrace page and the load the module with SDT probes before the sdt.ko in the DTrace/HowToAddSDTProbes page)? Bye, Alexander. -- BOFH excuse #378: Operators killed by year 2000 bug bite http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 11:11:11 +0100): pkgng is a binary package manager written from scratch for FreeBSD. I didn't had a look at it, just some comments about some parts you explained. features supported are or will be : - the register command can analyse elf files when registering a new port to discover forgotten dependencies if necessary. (done in alpha using libelf) This will probably fail if LD_LIBRARY_PATH is used, or if we are installing linuxulator ports. - new +MANIFEST (plist-like format) with new metadatas : options, arch, os version, etc. (done in the alpha) - pkgng supports checking arch of the package which means that users won't be able to install sparc64 binary package into amd64 machines. (not done yet) - a special architecture "all" allows to specify when a package can be used on every architecture. (not done yet) What if a package is able to install on a subset, e.g. the linuxulator ports are for amd64 and i386? In term of technology we decided to use a sqlite3 database, and to prevent potential trolling, sqlite3 is used in it's amalgamation form which means it is incorporated in the code sources (as recommanded by sqlite developpers like a statically linked library) on build we only activate the features we need in sqlite. The alpha release come with an experimental tool "pkg2ng" to convert an existing package database to the new pkgng database format. So one can test pkgng without rebuild all its packages. What about DB corruption/loss? Do you keep the /var/db/pkg//xxx files even with pkgng and only use the DB as a way to speed up some work (so the DB corruption just requires to run pkg2ng), or are you lost of the DB is lost? Bye, Alexander. -- Real computer scientists don't comment their code. The identifiers are so long they can't afford the disk space. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 15:14:52 +0100): 2011/3/25 Alexander Leidinger : Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 11:11:11 +0100): pkgng is a binary package manager written from scratch for FreeBSD. I didn't had a look at it, just some comments about some parts you explained. features supported are or will be : - a special architecture "all" allows to specify when a package can be used on every architecture. (not done yet) What if a package is able to install on a subset, e.g. the linuxulator ports are for amd64 and i386? No clue for that at the moment but we are open to suggestions. The suggestion is easy, allow a way to specify a set of valid architectures. What about DB corruption/loss? Do you keep the /var/db/pkg//xxx files even with pkgng and only use the DB as a way to speed up some work (so the DB corruption just requires to run pkg2ng), or are you lost of the DB is lost? Nothing is done about DB corruption/loss, I am not sure we need to do something. Maybe. I would say "for sure". Info: In Solaris 10 sqlite is used for the service managenemt framework (SMF). It is possible that the DB is corrupt in some bad situations. In this case you have to rebuild the DB (script provided, been there, had to use it). Currently a filesystem corruption/loss on /var/db/pkg would do the same. Put a corruption of /var/db/pkg/xyz-1/+REQUIRED_BY would only affect a small part, and this part could be even recovered from (pkgdb from portupgrade is able to do it). but it is sqlite so we can perhaps provide a way to get compressed dump so user can periodically backup their database. It needs to be automated. Maybe periodic daily... but maybe this is not often enough after a day of a lot of changes (think about it this way: do you want to lose a day of changes?). The current FS based DB is very robust, partly because there is redundant data, pertly because losing a file just means that the very limited subset of information is lost (and a reinstall of one port will fix it). Bye, Alexander. -- Programming is an unnatural act. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
on 25/03/2011 17:35 Pietro Cerutti said the following: > No need to look for strange scenarios, I'm surely going to sudo rm -f the file > more sooner than later, so... maybe just save a copy? I even can rm -rf / by accident. What's your solution to this? :) P.S. one solution would be a subcase of the other -- 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Fri, Mar 25, 2011 at 11:35 AM, Andriy Gapon wrote: > on 25/03/2011 17:35 Pietro Cerutti said the following: >> No need to look for strange scenarios, I'm surely going to sudo rm -f the >> file >> more sooner than later, so... maybe just save a copy? > > I even can rm -rf / by accident. > What's your solution to this? :) rm -rf / rm: "/" may not be removed -- Eitan Adler ___ 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 Fri, Mar 25, 2011 at 8:45 AM, Kurt Lidl wrote: > On Fri, Mar 25, 2011 at 10:40:44AM +0100, Johan van Selst wrote: >> Zhihao Yuan wrote: >> > > 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. >> > 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. >> >> Thank you for explaining. Indeed, all valid points and I fully agree >> that nvi-devel is not fit for inclusion in base as it is. In fact, the >> nvi from base is probably a better starting point (than nvi-devel) to >> create an editor that is fully compatible with nvi 1.79 and supports all >> multi-byte encodings. And when you, or someone, else creates such an >> editor, I will be pleased to remove the obsoleted port of nvi-devel. > > Has anyone looked at the nvi work that has taken place in NetBSD > in the last year or so? I have checked that. It's just a latest nvi 1.85. > > I think they've put in a bunch of wide character support. I'm not > sure if their DB code relies on bdb newer than what is in libc or not. > > -Kurt > -- 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: Switching to [KMGTPE]i prefixes?
One difference between this patch, and the patch I came up with, was that I used arrays of character pointers to the names of the symbols to use. This got around the problem that you have with the 'shift' you had to introduce to get things more or less correct. It also made for the possibility of having different kinds of units in the future that weren't a power of 2 -1 bytes long. It also simplified the code a little. Perhaps you would consider this improvement when devising future patches. Warner On Mar 24, 2011, at 8:46 PM, Alexander Best wrote: > here is a revised patch. it also includes the necessary changes to the > humanize_number(3) man page. > > 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 Mar 25 11, Warner Losh wrote: > One difference between this patch, and the patch I came up with, was that I > used arrays of character pointers to the names of the symbols to use. This > got around the problem that you have with the 'shift' you had to introduce to > get things more or less correct. It also made for the possibility of having > different kinds of units in the future that weren't a power of 2 -1 bytes > long. It also simplified the code a little. > > Perhaps you would consider this improvement when devising future patches. would you mind sharing your patch or pinpoint me to the according thread? cheers. alex > > Warner > > > On Mar 24, 2011, at 8:46 PM, Alexander Best wrote: > > > here is a revised patch. it also includes the necessary changes to the > > humanize_number(3) man page. > > > > 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" -- 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Fri, Mar 25, 2011 at 11:54:35AM -0500, Eitan Adler wrote: > On Fri, Mar 25, 2011 at 11:35 AM, Andriy Gapon wrote: > > on 25/03/2011 17:35 Pietro Cerutti said the following: > >> No need to look for strange scenarios, I'm surely going to sudo rm -f the > >> file > >> more sooner than later, so... maybe just save a copy? > > > > I even can rm -rf / by accident. > > What's your solution to this? :) > > rm -rf / > rm: "/" may not be removed referring to the CVS, this should improve the approach. cd /tmp rm -rf ../* ymmv -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgp63ospuJQq7.pgp Description: PGP signature
Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Fri, 25 Mar 2011 16:35:21 +0100 Pietro Cerutti wrote: > On 2011-Mar-25, 15:03, Julien Laffaye wrote: > > >>> What about DB corruption/loss? Do you keep > > >>> the /var/db/pkg//xxx files even with pkgng and only > > >>> use the DB as a way to speed up some work (so > > >>> the DB corruption just requires to run pkg2ng), or are you lost > > >>> of the DB is > > >>> lost? > > >>> > > >> > > >> Nothing is done about DB corruption/loss, I am not sure we need > > >> to do something. > > >> Maybe. > > > > > > I would say "for sure". Info: In Solaris 10 sqlite is used for > > > the service managenemt framework (SMF). It is possible that the > > > DB is corrupt in some bad situations. In this case you have to > > > rebuild the DB (script provided, been there, had to use it). > > > > If sqlite is properly used with transactions, it is very hard to > > corrupt the database. But if hardware lies to us and say that the And as I told above, I even had such a case (more than once), and the hardware was not buggy. What do you want to tell in this case, "life sucks, reinstall everything"? > > data is on disk whereas it isnt... what can we do? Sometimes you have to stay with broken hardware. > > Another potential problem is fsync(), but if it is broken on FreeBSD > > we want to fix it! > > > > BTW, the goal is to only have the database and not the flat files. > > If you are paranoid about power outage, use something like zfs > > snapshots... There are more FS than only ZFS (personally I use ZFS, and I have snapshots, but this is not a good solution for this problem). As I told already, if it isn't automatic, nearly nobody will use it. And the package management stuff has to be automatic, no freshman will think about setting up a snapshot script when he starts to use packages/ports. > No need to look for strange scenarios, I'm surely going to sudo rm -f > the file more sooner than later, so... maybe just save a copy? A copy or two would be enough, but it has to be done automatically, and once a day is not enough. A copy after each X modifications maybe (for suitable definitions of X and 'modifications'). Bye, Alexander. ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
As far as package managers go, yum, which is used widely, uses SQLite. -- Peace cannot be achieved through violence, it can only be attained through understanding. ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Fri, Mar 25, 2011 at 1:14 PM, Alexander Leidinger wrote: > On Fri, 25 Mar 2011 16:35:21 +0100 Pietro Cerutti > wrote: > >> On 2011-Mar-25, 15:03, Julien Laffaye wrote: >> > >>> What about DB corruption/loss? Do you keep >> > >>> the /var/db/pkg//xxx files even with pkgng and only >> > >>> use the DB as a way to speed up some work (so >> > >>> the DB corruption just requires to run pkg2ng), or are you lost >> > >>> of the DB is >> > >>> lost? >> > >>> >> > >> >> > >> Nothing is done about DB corruption/loss, I am not sure we need >> > >> to do something. >> > >> Maybe. >> > > >> > > I would say "for sure". Info: In Solaris 10 sqlite is used for >> > > the service managenemt framework (SMF). It is possible that the >> > > DB is corrupt in some bad situations. In this case you have to >> > > rebuild the DB (script provided, been there, had to use it). >> > >> > If sqlite is properly used with transactions, it is very hard to >> > corrupt the database. But if hardware lies to us and say that the > > And as I told above, I even had such a case (more than once), and the > hardware was not buggy. What do you want to tell in this case, "life > sucks, reinstall everything"? If you use binary packages, pulling down everything should be trivial, fast, and easy to install. If you're using ports, well then things are going to be slow as expected. >> > data is on disk whereas it isnt... what can we do? > > Sometimes you have to stay with broken hardware. Sometimes you have to go buy new parts? Playing with broken hardware is like playing with fire -- sometimes you'll get burned if it goes out of commission during critical operations. I would be more concerned about overall system operation than having a packaging system that can handle all error conditions that should be rightfully handled by various kernel subsystems. If the kernel's doing it's job, then the packaging manager can do its job as well. >> > Another potential problem is fsync(), but if it is broken on FreeBSD >> > we want to fix it! >> > >> > BTW, the goal is to only have the database and not the flat files. >> > If you are paranoid about power outage, use something like zfs >> > snapshots... > > There are more FS than only ZFS (personally I use ZFS, and I have > snapshots, but this is not a good solution for this problem). A lot of filesystems feature snapshot'ing, including UFS. If you aren't smart enough to back up your data you're toast if the data is gone. I would be more concerned about the program getting killed, not getting properly cleaned up, etc as this is something that the package manager frontend (or whatever the official name is) should catch and fail gracefully with. Things need to follow an ACID methodology and be recoverable in the event that it can't be ACID, or it's no better than pkg_install/ports currently is if it's caught in the middle of a critical operation today installing or removing software. If SQLite can't deliver this level of ACID-like capability, then pkg_install needs to be redesigned. > As I told already, if it isn't automatic, nearly nobody will use it. > And the package management stuff has to be automatic, no freshman will > think about setting up a snapshot script when he starts to use > packages/ports. I'd just provide an export command to print out a (JSON?) version of the information, and move on. None of the other major packaging systems out there that I know of use flat files for this data, and I would rather not make it automatic because it's an unnecessary performance hit. If the user feels the need for backing up his/her data they will. If not, they're SoL in the event of a crash. >> No need to look for strange scenarios, I'm surely going to sudo rm -f >> the file more sooner than later, so... maybe just save a copy? > > A copy or two would be enough, but it has to be done automatically, and > once a day is not enough. A copy after each X modifications maybe > (for suitable definitions of X and 'modifications'). Please see my comment above. There's no reason why this belongs in a packaging system (you can add it as an external tool, but the point is to avoid architectural mistakes that leaked into the old pkg_install over the period of 10 years or so). Thanks, -Garrett PS Sorry for being so hardnosed on this, but I want something that's fast and correct, instead of something bloated, slow, half-baked, harder to test, etc. pkg_install gets executed enough times during a port upgrade that having something more streamlined for most usecases is the only way to go, and there's enough code that doesn't get executed on a regular basis that has no business being in pkg_install. ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
2011/3/25 Yuri : > On 03/25/2011 03:11, Baptiste Daroussin wrote: >> >> Julien Laffaye (jlaffaye@) and I, helped by Philippe Pepiot (huge >> contributor) have been working since the end of the last GSoC on a >> rewrite of pkg_install. >> >> pkgng is a binary package manager written from scratch for FreeBSD. >> > > How does it relate to portmaster and portupgrade packages, which both have > (or include) supposedly the same functionality? > > Yuri > both have to be adapted, portupgrade throught maybe some ruby bindings to libpkg, portmaster by patching it to use pkg frontend instead of pkg_* tools (as I did for the ports (see ports/bsd.pkgng.mk in the git tree) regards, Bapt ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On 03/25/2011 03:11, Baptiste Daroussin wrote: Julien Laffaye (jlaffaye@) and I, helped by Philippe Pepiot (huge contributor) have been working since the end of the last GSoC on a rewrite of pkg_install. pkgng is a binary package manager written from scratch for FreeBSD. How does it relate to portmaster and portupgrade packages, which both have (or include) supposedly the same functionality? Yuri ___ 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?
FYI I have a patch and I have incorporated some of Alexander's idea.
Difference:
- Use of both HN_DIVISOR_1000 and HN_IEC_PREFIXES triggers an
assertion. I think it doesn't make sense to return since this is an
API violation and we should just tell the caller explicitly;
- DIVISOR_1000 and !1000 cases use just same prefixes, so merge them
while keeping divisor intact;
- Make prefixes table consistently long. I have no strong opinion on
this one, though, it's just what my original version used and I can
change it to the way Alexander did if there is an advantage of doing
that way.
(Note, it seems that we use HN_ prefix for both 'scale' and 'flags', I
have sorted them by value but HN_IEC_PREFIXES should really belong to
the flags group).
Cheers,
--
Xin LI http://www.delphij.net
Index: humanize_number.c
===
--- humanize_number.c (revision 220009)
+++ humanize_number.c (working copy)
@@ -54,29 +54,31 @@
assert(buf != NULL);
assert(suffix != NULL);
assert(scale >= 0);
+ assert(!((flags & HN_DIVISOR_1000) && (flags & HN_IEC_PREFIXES)));
remainder = 0;
- if (flags & HN_DIVISOR_1000) {
- /* SI for decimal multiplies */
- divisor = 1000;
+ if (flags & HN_IEC_PREFIXES) {
+ baselen = 2;
+ divisor = 1024;
if (flags & HN_B)
- prefixes = "B\0k\0M\0G\0T\0P\0E";
+ prefixes = "B\0\0Ki\0Mi\0Gi\0Ti\0Pi\0Ei";
else
- prefixes = "\0\0k\0M\0G\0T\0P\0E";
+ prefixes = "\0\0Ki\0Mi\0Gi\0Ti\0Pi\0Ei";
} else {
- /*
- * binary multiplies
- * XXX IEC 60027-2 recommends Ki, Mi, Gi...
- */
- divisor = 1024;
+ baselen = 1;
+ if (flags & HN_DIVISOR_1000)
+ divisor = 1000;
+ else
+ divisor = 1024;
+
if (flags & HN_B)
- prefixes = "B\0K\0M\0G\0T\0P\0E";
+ prefixes = "B\0\0k\0\0M\0\0G\0\0T\0\0P\0\0E";
else
- prefixes = "\0\0K\0M\0G\0T\0P\0E";
+ prefixes = "\0\0\0k\0\0M\0\0G\0\0T\0\0P\0\0E";
}
-#define SCALE2PREFIX(scale) (&prefixes[(scale) << 1])
+#define SCALE2PREFIX(scale) (&prefixes[(scale) * 3])
maxscale = 7;
if (scale >= maxscale &&
@@ -91,10 +93,10 @@
if (quotient < 0) {
sign = -1;
quotient = -quotient;
- baselen = 3; /* sign, digit, prefix */
+ baselen += 2; /* sign, digit */
} else {
sign = 1;
- baselen = 2; /* digit, prefix */
+ baselen += 1; /* digit */
}
if (flags & HN_NOSPACE)
sep = "";
Index: libutil.h
===
--- libutil.h (revision 220009)
+++ libutil.h (working copy)
@@ -223,6 +223,7 @@
#define HN_GETSCALE 0x10
#define HN_AUTOSCALE 0x20
+#define HN_IEC_PREFIXES 0x40
/* hexdump(3) */
#define HD_COLUMN_MASK 0xff
___
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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Fri, 25 Mar 2011 13:47:13 -0700 Garrett Cooper wrote: > On Fri, Mar 25, 2011 at 1:14 PM, Alexander Leidinger > wrote: > > On Fri, 25 Mar 2011 16:35:21 +0100 Pietro Cerutti > > wrote: > > > >> On 2011-Mar-25, 15:03, Julien Laffaye wrote: > >> > >>> What about DB corruption/loss? Do you keep > >> > >>> the /var/db/pkg//xxx files even with pkgng and only > >> > >>> use the DB as a way to speed up some work (so > >> > >>> the DB corruption just requires to run pkg2ng), or are you > >> > >>> lost of the DB is > >> > >>> lost? > >> > >>> > >> > >> > >> > >> Nothing is done about DB corruption/loss, I am not sure we > >> > >> need to do something. > >> > >> Maybe. > >> > > > >> > > I would say "for sure". Info: In Solaris 10 sqlite is used for > >> > > the service managenemt framework (SMF). It is possible that the > >> > > DB is corrupt in some bad situations. In this case you have to > >> > > rebuild the DB (script provided, been there, had to use it). > >> > > >> > If sqlite is properly used with transactions, it is very hard to > >> > corrupt the database. But if hardware lies to us and say that the > > > > And as I told above, I even had such a case (more than once), and > > the hardware was not buggy. What do you want to tell in this case, > > "life sucks, reinstall everything"? > > If you use binary packages, pulling down everything should be trivial, > fast, and easy to install. If you're using ports, well then things are > going to be slow as expected. And if there is a fast way to cut down the slow part... why not? > >> > data is on disk whereas it isnt... what can we do? > > > > Sometimes you have to stay with broken hardware. > > Sometimes you have to go buy new parts? Yes, but if we talk e.g. about aging hardware, having the luck to get hit directly in the parts which hurt is not nice. You want to have the time to find a suitable replacement. > Playing with broken hardware is like playing with fire -- sometimes > you'll get burned if it goes out of commission during critical > operations. I would be more concerned about overall system operation > than having a packaging system that can handle all error conditions > that should be rightfully handled by various kernel subsystems. If the > kernel's doing it's job, then the packaging manager can do its job as > well. You know that the world is not an ideal one. Shit happens and Murphy visits you. > >> > Another potential problem is fsync(), but if it is broken on > >> > FreeBSD we want to fix it! > >> > > >> > BTW, the goal is to only have the database and not the flat > >> > files. If you are paranoid about power outage, use something > >> > like zfs snapshots... > > > > There are more FS than only ZFS (personally I use ZFS, and I have > > snapshots, but this is not a good solution for this problem). > > A lot of filesystems feature snapshot'ing, including UFS. If you > aren't smart enough to back up your data you're toast if the data is > gone. So... why do we have /var/backups/master.passwd.bak then? To make life easy. > I would be more concerned about the program getting killed, not > getting properly cleaned up, etc as this is something that the package > manager frontend (or whatever the official name is) should catch and > fail gracefully with. Things need to follow an ACID methodology and be > recoverable in the event that it can't be ACID, or it's no better than > pkg_install/ports currently is if it's caught in the middle of a > critical operation today installing or removing software. I agree. > If SQLite can't deliver this level of ACID-like capability, then > pkg_install needs to be redesigned. AFAIK it can. > > As I told already, if it isn't automatic, nearly nobody will use it. > > And the package management stuff has to be automatic, no freshman > > will think about setting up a snapshot script when he starts to use > > packages/ports. > > I'd just provide an export command to print out a (JSON?) > version of the information, and move on. None of the other major > packaging systems out there that I know of use flat files for this > data, and I would rather not make it automatic because it's an > unnecessary performance hit. If the user feels the need for backing up > his/her data they will. If not, they're SoL in the event of a crash. - It does not need to be done with every change. - You do not know if it is a performance hit or not, we do not have numbers. - If making an automatic export after X modifications is not expensive, I say: why not? It would make more easy in case of fire. > >> No need to look for strange scenarios, I'm surely going to sudo rm > >> -f the file more sooner than later, so... maybe just save a copy? > > > > A copy or two would be enough, but it has to be done automatically, > > and once a day is not enough. A copy after each X modifications > > maybe (for suitable definitions of X and 'modifications'). > > Please see my comment above. There's no reason why this belongs in a > packag
Re: Switching to [KMGTPE]i prefixes?
On Fri Mar 25 11, Xin LI wrote: > FYI I have a patch and I have incorporated some of Alexander's idea. > > Difference: > > - Use of both HN_DIVISOR_1000 and HN_IEC_PREFIXES triggers an > assertion. I think it doesn't make sense to return since this is an > API violation and we should just tell the caller explicitly; actually i vote for removing all asserts in humanize_number.c and return -1 based upon the later checks. the existing assert(buf != NULL); assert(suffix != NULL); checks aren't really needed, since buf and suffix are also checked later on. so just having: if (scale <= 0 || (scale >= maxscale && (scale & (HN_AUTOSCALE | HN_GETSCALE)) == 0)) return (-1); if (buf == NULL || suffix == NULL) return (-1); if ((flags & (HN_DIVISOR_1000 | HN_IEC_PREFIXES)) == 0) return (-1); ...should be enough. > - DIVISOR_1000 and !1000 cases use just same prefixes, so merge them > while keeping divisor intact; good idea. however i think you should add a comment to point out that the default behavior is !DIVISOR_1000 && !HN_IEC_PREFIXES. one has to look very closely to find out. > - Make prefixes table consistently long. I have no strong opinion on > this one, though, it's just what my original version used and I can > change it to the way Alexander did if there is an advantage of doing > that way. i think the way you're doing it is nicer than how i implemented it. > > (Note, it seems that we use HN_ prefix for both 'scale' and 'flags', I > have sorted them by value but HN_IEC_PREFIXES should really belong to > the flags group). this is odd indeed. actually the possible 'scale' and 'flags' flags should not have the same prefixes. but it appears we're stuck with this. i think sorting me should sort them into the two groups and not value wise. so it's #define HN_DECIMAL 0x01 #define HN_NOSPACE 0x02 #define HN_B0x04 #define HN_DIVISOR_1000 0x08 #define HN_IEC_PREFIXES 0x40 #define HN_GETSCALE 0x10 #define HN_AUTOSCALE0x20 > > Cheers, > -- > Xin LI http://www.delphij.net -- 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: Switching to [KMGTPE]i prefixes?
On Fri Mar 25 11, Alexander Best wrote:
> On Fri Mar 25 11, Xin LI wrote:
> > FYI I have a patch and I have incorporated some of Alexander's idea.
this is what i had in mind (see attached patch).
cheers.
alex
> >
> > Difference:
> >
> > - Use of both HN_DIVISOR_1000 and HN_IEC_PREFIXES triggers an
> > assertion. I think it doesn't make sense to return since this is an
> > API violation and we should just tell the caller explicitly;
>
> actually i vote for removing all asserts in humanize_number.c and return -1
> based upon the later checks.
>
> the existing
>
> assert(buf != NULL);
> assert(suffix != NULL);
>
> checks aren't really needed, since buf and suffix are also checked later on.
> so
> just having:
>
> if (scale <= 0 || (scale >= maxscale &&
> (scale & (HN_AUTOSCALE | HN_GETSCALE)) == 0))
> return (-1);
>
> if (buf == NULL || suffix == NULL)
> return (-1);
>
> if ((flags & (HN_DIVISOR_1000 | HN_IEC_PREFIXES)) == 0)
> return (-1);
>
> ...should be enough.
>
> > - DIVISOR_1000 and !1000 cases use just same prefixes, so merge them
> > while keeping divisor intact;
>
> good idea. however i think you should add a comment to point out that the
> default behavior is !DIVISOR_1000 && !HN_IEC_PREFIXES. one has to look very
> closely to find out.
>
> > - Make prefixes table consistently long. I have no strong opinion on
> > this one, though, it's just what my original version used and I can
> > change it to the way Alexander did if there is an advantage of doing
> > that way.
>
> i think the way you're doing it is nicer than how i implemented it.
>
> >
> > (Note, it seems that we use HN_ prefix for both 'scale' and 'flags', I
> > have sorted them by value but HN_IEC_PREFIXES should really belong to
> > the flags group).
>
> this is odd indeed. actually the possible 'scale' and 'flags' flags should
> not have the same prefixes. but it appears we're stuck with this.
>
> i think sorting me should sort them into the two groups and not value wise.
> so it's
>
> #define HN_DECIMAL 0x01
> #define HN_NOSPACE 0x02
> #define HN_B0x04
> #define HN_DIVISOR_1000 0x08
> #define HN_IEC_PREFIXES 0x40
>
> #define HN_GETSCALE 0x10
> #define HN_AUTOSCALE0x20
>
> >
> > Cheers,
> > --
> > Xin LI http://www.delphij.net
>
>
>
> --
> a13x
--
a13x
diff --git a/lib/libutil/humanize_number.c b/lib/libutil/humanize_number.c
index 75bcb46..e086478 100644
--- a/lib/libutil/humanize_number.c
+++ b/lib/libutil/humanize_number.c
@@ -33,11 +33,8 @@
#include
__FBSDID("$FreeBSD$");
-#include
-#include
#include
#include
-#include
#include
#include
#include
@@ -51,50 +48,50 @@ humanize_number(char *buf, size_t len, int64_t quotient,
int64_t divisor, max;
size_t baselen;
- assert(buf != NULL);
- assert(suffix != NULL);
- assert(scale >= 0);
-
remainder = 0;
- if (flags & HN_DIVISOR_1000) {
- /* SI for decimal multiplies */
- divisor = 1000;
+ if (flags & HN_IEC_PREFIXES) {
+ baselen = 2;
+ divisor = 1024;
if (flags & HN_B)
- prefixes = "B\0k\0M\0G\0T\0P\0E";
+ prefixes = "B\0\0Ki\0Mi\0Gi\0Ti\0Pi\0Ei";
else
- prefixes = "\0\0k\0M\0G\0T\0P\0E";
- } else {
- /*
-* binary multiplies
-* XXX IEC 60027-2 recommends Ki, Mi, Gi...
-*/
- divisor = 1024;
+ prefixes = "\0\0Ki\0Mi\0Gi\0Ti\0Pi\0Ei";
+ else {
+ baselen = 1;
+ if (flags & HN_DIVISOR_1000)
+ divisor = 1000;
+ else
+ /* default case */
+ divisor = 1024;
if (flags & HN_B)
- prefixes = "B\0K\0M\0G\0T\0P\0E";
+ prefixes = "B\0\0k\0\0M\0\0G\0\0T\0\0P\0\0E";
else
- prefixes = "\0\0K\0M\0G\0T\0P\0E";
+ prefixes = "\0\0\0k\0\0M\0\0G\0\0T\0\0P\0\0E";
}
-#defineSCALE2PREFIX(scale) (&prefixes[(scale) << 1])
- maxscale = 7;
+#defineSCALE2PREFIX(scale) (&prefixes[(scale) * 3])
+ maxscale = 7; /* XXX cannot scale past `exa' */
- if (scale >= maxscale &&
- (scale & (HN_AUTOSCALE | HN_GETSCALE)) == 0)
+ if (scale <= 0 || (scale >= maxscale &&
+ (scale & (HN_AUTOSCALE | HN_GETSCALE)) == 0))
return (-1);
if (buf == NULL || suffix == NULL)
return (-1);
+ if (flags & (HN_DIVISOR_1000 | HN_IEC_PREFIXES))
+ return (-1);
+
if (len > 0)
buf[0] = '\0';
Re: Switching to [KMGTPE]i prefixes?
On Mar 25, 2011, at 3:33 PM, Xin LI wrote: > FYI I have a patch and I have incorporated some of Alexander's idea. > > Difference: > > - Use of both HN_DIVISOR_1000 and HN_IEC_PREFIXES triggers an > assertion. I think it doesn't make sense to return since this is an > API violation and we should just tell the caller explicitly; > - DIVISOR_1000 and !1000 cases use just same prefixes, so merge them > while keeping divisor intact; > - Make prefixes table consistently long. I have no strong opinion on > this one, though, it's just what my original version used and I can > change it to the way Alexander did if there is an advantage of doing > that way. I did this in my first iteration, but switched to the array version after. Either is good, honestly. > (Note, it seems that we use HN_ prefix for both 'scale' and 'flags', I > have sorted them by value but HN_IEC_PREFIXES should really belong to > the flags group). How did you guys deal with programs like df that now need to do special buffer size hacks to get consistent results? Warner ___ 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, Mar 25, 2011 at 3:32 PM, Alexander Best wrote:
> On Fri Mar 25 11, Xin LI wrote:
>> FYI I have a patch and I have incorporated some of Alexander's idea.
>>
>> Difference:
>>
>> - Use of both HN_DIVISOR_1000 and HN_IEC_PREFIXES triggers an
>> assertion. I think it doesn't make sense to return since this is an
>> API violation and we should just tell the caller explicitly;
>
> actually i vote for removing all asserts in humanize_number.c and return -1
> based upon the later checks.
>
> the existing
>
> assert(buf != NULL);
> assert(suffix != NULL);
>
> checks aren't really needed, since buf and suffix are also checked later on.
> so
> just having:
Well, one of my believes is that a program should crash as early as
possible, and with clear statement about "Why I crashed", when it's
compiled with debugging aids, like assertions. To test or not to test
these cases in a release binary on the other hand really depends on
whether there is security or other bad implications. This generally
makes developers' life easier, as they don't have to pursue into the
code to find out why the program crashed, etc.
Unlike system calls, humanize_number(3) does not indicate what's wrong
via errno, e.g. it tells you "No I can't" rather than a reason of "Why
I can't do that". Assertions here gives it an opportunity to say it
loudly.
If however the program is compiled with -DNDEBUG, these assertions
would became no-op. At this stage, in my opinion, only basic tests
should be done and we fall back to returning -1, or at least, not
crash the program in a mysterious way.
For this reasons, I think the assertion here against flags is right,
it does not hurt if we proceed with both flags set, as we do not
access undefined memory nor overwrite undefined memory. Furthermore,
these values are more likely to be hard-wired at caller, where the
assertion should catch the case.
> if (scale <= 0 || (scale >= maxscale &&
> (scale & (HN_AUTOSCALE | HN_GETSCALE)) == 0))
> return (-1);
I think this one is good to have for both assertion and tests. Note
that I think it should be scale < 0 here, scale == 0 seems to be a
valid value.
> if (buf == NULL || suffix == NULL)
> return (-1);
This duplication is necessary in my opinion. It's a protection
against NULL pointer deference at runtime.
> if ((flags & (HN_DIVISOR_1000 | HN_IEC_PREFIXES)) == 0)
> return (-1);
I'd vote no for this one for the reason above.
>> - DIVISOR_1000 and !1000 cases use just same prefixes, so merge them
>> while keeping divisor intact;
>
> good idea. however i think you should add a comment to point out that the
> default behavior is !DIVISOR_1000 && !HN_IEC_PREFIXES. one has to look very
> closely to find out.
Will do.
> #define HN_DECIMAL 0x01
> #define HN_NOSPACE 0x02
> #define HN_B 0x04
> #define HN_DIVISOR_1000 0x08
> #define HN_IEC_PREFIXES 0x40
>
> #define HN_GETSCALE 0x10
> #define HN_AUTOSCALE 0x20
Thinking again and I think we are just fine to use HN_IEC_PREFIXES ==
0x10 here. I don't think there is a reason why we can't use 0x10 for
flags.
Here is what in my mind. I have stolen some comments from your
version of patch to explain the meaning of the HN_IEC_PREFIXES option
as well.
--
Xin LI http://www.delphij.net
Index: humanize_number.c
===
--- humanize_number.c (revision 220009)
+++ humanize_number.c (working copy)
@@ -42,45 +42,59 @@
#include
#include
+static const int maxscale = 7;
+
int
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, s1, s2, sign;
int64_t divisor, max;
size_t baselen;
assert(buf != NULL);
assert(suffix != NULL);
assert(scale >= 0);
+ assert(scale < maxscale || (((scale & (HN_AUTOSCALE | HN_GETSCALE)) != 0)));
+ assert(!((flags & HN_DIVISOR_1000) && (flags & HN_IEC_PREFIXES)));
remainder = 0;
- if (flags & HN_DIVISOR_1000) {
- /* SI for decimal multiplies */
- divisor = 1000;
- 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) {
+ baselen = 2;
/*
- * binary multiplies
- * XXX IEC 60027-2 recommends Ki, Mi, Gi...
+ * Use the prefixes for power of two recommended by
+ * the International Electrotechnical Commission
+ * (IEC) in IEC 8-3 (superseeding IEC 60027-2)
+ * (i.e. Ki, Mi, Gi...).
+ *
+ * HN_IEC_PREFIXES implies a divisor of 1024 here
+ * (use of HN_DIVISOR_1000 would have triggered
+ * an assertion earlier).
*/
divisor = 1024;
if (flags & HN_B)
- prefixes = "B\0K\0M\0G\0T\0P\0E";
+ prefixes = "B\0\0Ki\0Mi\0Gi\0Ti\0Pi\0Ei";
else
- prefixes = "\0\0K\0M\0G\0T\0P\
Re: Switching to [KMGTPE]i prefixes?
On Fri, Mar 25, 2011 at 2:50 PM, Warner Losh wrote: > How did you guys deal with programs like df that now need to do special > buffer size hacks to get consistent results? I think it doesn't really matter - caller have to specify using IEC prefixes explicitly, so old binaries won't be broken. They must be updated to use the IEC prefixes. Cheers, -- Xin LI http://www.delphij.net ___ 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 Mar 25, 2011, at 5:28 PM, Xin LI wrote: > On Fri, Mar 25, 2011 at 2:50 PM, Warner Losh wrote: >> How did you guys deal with programs like df that now need to do special >> buffer size hacks to get consistent results? > > I think it doesn't really matter - caller have to specify using IEC > prefixes explicitly, so old binaries won't be broken. They must be > updated to use the IEC prefixes. My patch had a 'force IEC prefixes' compile time option which did. However, you'll have to monkey around with df to get it to do the right thing since the buffer sizes and such will need to be 1 longer for the extra 'i' in the mix now... And it can' t be unconditional, since then you'd get different results with the non IEC case. That's a short way of saying that this patch is necessary, but not sufficient for the current system. We'll need a lot of tweaks to the rest of the system for it to behave correctly. Warner ___ 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 Mar 25 11, Xin LI wrote: > On Fri, Mar 25, 2011 at 3:32 PM, Alexander Best wrote: > > On Fri Mar 25 11, Xin LI wrote: > >> FYI I have a patch and I have incorporated some of Alexander's idea. > >> > >> Difference: > >> > >> - Use of both HN_DIVISOR_1000 and HN_IEC_PREFIXES triggers an > >> assertion. I think it doesn't make sense to return since this is an > >> API violation and we should just tell the caller explicitly; > > > > actually i vote for removing all asserts in humanize_number.c and return -1 > > based upon the later checks. > > > > the existing > > > > assert(buf != NULL); > > assert(suffix != NULL); > > > > checks aren't really needed, since buf and suffix are also checked later > > on. so > > just having: > > Well, one of my believes is that a program should crash as early as > possible, and with clear statement about "Why I crashed", when it's > compiled with debugging aids, like assertions. To test or not to test > these cases in a release binary on the other hand really depends on > whether there is security or other bad implications. This generally > makes developers' life easier, as they don't have to pursue into the > code to find out why the program crashed, etc. > > Unlike system calls, humanize_number(3) does not indicate what's wrong > via errno, e.g. it tells you "No I can't" rather than a reason of "Why > I can't do that". Assertions here gives it an opportunity to say it > loudly. > > If however the program is compiled with -DNDEBUG, these assertions > would became no-op. At this stage, in my opinion, only basic tests > should be done and we fall back to returning -1, or at least, not > crash the program in a mysterious way. > > For this reasons, I think the assertion here against flags is right, > it does not hurt if we proceed with both flags set, as we do not > access undefined memory nor overwrite undefined memory. Furthermore, > these values are more likely to be hard-wired at caller, where the > assertion should catch the case. > > > if (scale <= 0 || (scale >= maxscale && > > (scale & (HN_AUTOSCALE | HN_GETSCALE)) == 0)) > > return (-1); > > I think this one is good to have for both assertion and tests. Note > that I think it should be scale < 0 here, scale == 0 seems to be a > valid value. > > > if (buf == NULL || suffix == NULL) > > return (-1); > > This duplication is necessary in my opinion. It's a protection > against NULL pointer deference at runtime. > > > if ((flags & (HN_DIVISOR_1000 | HN_IEC_PREFIXES)) == 0) > > return (-1); > > I'd vote no for this one for the reason above. > > >> - DIVISOR_1000 and !1000 cases use just same prefixes, so merge them > >> while keeping divisor intact; > > > > good idea. however i think you should add a comment to point out that the > > default behavior is !DIVISOR_1000 && !HN_IEC_PREFIXES. one has to look very > > closely to find out. > > Will do. > > > #define HN_DECIMAL 0x01 > > #define HN_NOSPACE 0x02 > > #define HN_B 0x04 > > #define HN_DIVISOR_1000 0x08 > > #define HN_IEC_PREFIXES 0x40 > > > > #define HN_GETSCALE 0x10 > > #define HN_AUTOSCALE 0x20 > > Thinking again and I think we are just fine to use HN_IEC_PREFIXES == > 0x10 here. I don't think there is a reason why we can't use 0x10 for > flags. > > Here is what in my mind. I have stolen some comments from your > version of patch to explain the meaning of the HN_IEC_PREFIXES option > as well. very nice. to me the patch looks close to perfect and most importantly it won't break anything. :) even though the patch won't have any direct impact, it enables all other base utilities to make use of the IEC prefixes. no idea how that turns out. maybe the community votes to keep the current prefixes. the main point however is: now there's a chance to chose. :) i think the patch also requires a few humanize_number(3) man page changes. you might want to cherry pick from http://people.freebsd.org/~arundel/drafts/libutil.diff ...my changes to the man page are probably a bit too elaborate. cheers. alex > > -- > Xin LI http://www.delphij.net -- 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Fri, 25 Mar 2011 15:14:52 +0100 Baptiste Daroussin wrote: > 2011/3/25 Alexander Leidinger : > >> - the register command can analyse elf files when registering a new port > >> to > >> discover forgotten dependencies if necessary. (done in alpha using libelf) > > This will probably fail if LD_LIBRARY_PATH is used, or if we are installing > > linuxulator ports. > this isn't activated by default, and if activated is only intended to > work on freebsd elf files. > This is done to workaround some bugguy ports not to be used in > production, pkg register shows in warning in that case so that > user/maintainers are warned they have something to fix. How about dealing with 32-bit x86 packages on an amd64 install? http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.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: [GSoC] About the idea: Unicode support in vi
On Fri, Mar 25, 2011 at 1:39 PM, Zhihao Yuan wrote: > On Fri, Mar 25, 2011 at 8:45 AM, Kurt Lidl wrote: >> On Fri, Mar 25, 2011 at 10:40:44AM +0100, Johan van Selst wrote: >>> Zhihao Yuan wrote: >>> > > 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. >>> > 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. >>> >>> Thank you for explaining. Indeed, all valid points and I fully agree >>> that nvi-devel is not fit for inclusion in base as it is. In fact, the >>> nvi from base is probably a better starting point (than nvi-devel) to >>> create an editor that is fully compatible with nvi 1.79 and supports all >>> multi-byte encodings. And when you, or someone, else creates such an >>> editor, I will be pleased to remove the obsoleted port of nvi-devel. >> >> Has anyone looked at the nvi work that has taken place in NetBSD >> in the last year or so? > > I have checked that. It's just a latest nvi 1.85. > >> >> I think they've put in a bunch of wide character support. I'm not >> sure if their DB code relies on bdb newer than what is in libc or not. >> >> -Kurt >> > > -- > Zhihao Yuan > The best way to predict the future is to invent it. > Sorry to spam in the group... Since the application time is coming, I do need a possible mentor. I was told that nvi in the base system was not managed by a dedicated people. So I hope I can talk with someone who is free during the summer, and has some interests to help me :) -- 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"
