Re: Make ZFS use the physical sector size when computing initial ashift
"Steven Hartland" writes: > Hi DES, unfortunately you need a quite bit more than this to work > compatibly. *chirp* *chirp* *chirp* DES -- Dag-Erling Smørgrav - d...@des.no ___ 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"
Make ZFS use the physical sector size when computing initial ashift
The attached patch causes ZFS to base the minimum transfer size for a new vdev on the GEOM provider's stripesize (physical sector size) rather than sectorsize (logical sector size), provided that stripesize is a power of two larger than sectorsize and smaller than or equal to VDEV_PAD_SIZE. This should eliminate the need for ivoras@'s gnop trick when creating ZFS pools on Advanced Format drives. DES -- Dag-Erling Smørgrav - d...@des.no Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c === --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c (revision 253138) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c (working copy) @@ -578,6 +578,7 @@ { struct g_provider *pp; struct g_consumer *cp; + u_int sectorsize; size_t bufsize; int error; @@ -661,8 +662,21 @@ /* * Determine the device's minimum transfer size. + * + * This is a bit of a hack. For performance reasons, we would + * prefer to use the physical sector size (reported by GEOM as + * stripesize) as minimum transfer size. However, doing so + * unconditionally would break existing vdevs. Therefore, we + * compute ashift based on stripesize when the vdev isn't already + * part of a pool (vdev_asize == 0), and sectorsize otherwise. */ - *ashift = highbit(MAX(pp->sectorsize, SPA_MINBLOCKSIZE)) - 1; + if (vd->vdev_asize == 0 && pp->stripesize > pp->sectorsize && + ISP2(pp->stripesize) && pp->stripesize <= VDEV_PAD_SIZE) { + sectorsize = pp->stripesize; + } else { + sectorsize = pp->sectorsize; + } + *ashift = highbit(MAX(sectorsize, SPA_MINBLOCKSIZE)) - 1; /* * Clear the nowritecache settings, so that on a vdev_reopen() ___ 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: considering i386 as a tier 1 architecture
Mehmet Erol Sanliturk writes: > I am NOT able to understand the merit of these products with respect > to their features and PRICES. Please stop SHOUTING, and learn to accept and respect the fact that other people have other opinions and priorities than you do, and to stop trying to force your worldview on them. Maybe they know something you haven't learned yet. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: considering i386 as a tier 1 architecture
Wojciech Puchar writes: > Lev Serebryakov writes: > > It is not exact so. Some Atoms on some motherboards with some > > firmwares are 64-bit CPU. > don't know of any now in shops that are not http://soekris.com/products/net5501.html http://soekris.com/products/net6501.html DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: considering i386 as a tier 1 architecture
Mehmet Erol Sanliturk writes: > Since I am not a developer or user of such a system , I can not say > whether 25000 packages are necessary for them or not. Reducing any > amount of work load which its outcome is not directly used is a > contribution to the FreeBSD project by diverting such efforts to other > man power or resources required areas. You're assuming that maintaining i386 as a tier 1 platform really *does* add significantly to our workload. You should also check your calendar :) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: considering i386 as a tier 1 architecture
Mehmet Erol Sanliturk writes: > At present, there is NO any processor which is ONLY 32-bits. All the world is not a PC. There are still 32-bit x86-based embedded or small-form-factor systems, such as the soekris net5501 and net6501, which are widely used in the BSD community. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Turn on CLANG_IS_CC when not building gcc
Dimitry Andric writes: > Dag-Erling Smørgrav writes: > > The following patches (for head and stable/9) automatically enables > > CLANG_IS_CC if GCC is disabled but CLANG is not. Any objections? > This looks fine to me. Otherwise, if ${CC} isn't set to clang, > buildworld might fail in mysterious ways... :) Not mysterious at all - it fails while building xlint in the cross-tools phase because, while bsd.{lib,prog}.mk invoke the compiler as "clang" and not "cc", lint itself tries invokes "cc" to generate the lint libraries (/usr/libdata/lint/llib-l{posix,stdc}.ln). DES -- Dag-Erling Smørgrav - d...@des.no ___ 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"
Turn on CLANG_IS_CC when not building gcc
The following patches (for head and stable/9) automatically enable CLANG_IS_CC if GCC is disabled but CLANG is not. Any objections? Index: head/share/mk/bsd.own.mk === --- head/share/mk/bsd.own.mk(revision 246325) +++ head/share/mk/bsd.own.mk(working copy) @@ -526,6 +526,8 @@ MK_CLANG_EXTRAS:= no MK_CLANG_FULL:= no MK_CLANG_IS_CC:= no +.elif ${MK_GCC} == "no" +MK_CLANG_IS_CC:= yes .endif # Index: stable/9/share/mk/bsd.own.mk === --- stable/9/share/mk/bsd.own.mk(revision 244989) +++ stable/9/share/mk/bsd.own.mk(working copy) @@ -581,6 +581,8 @@ .if ${MK_CLANG} == "no" MK_CLANG_IS_CC:= no +.elif ${MK_GCC} == "no" +MK_CLANG_IS_CC:= yes .endif MK_LIBCPLUSPLUS?= no DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: FreeBSD needs Git to ensure repo integrity
grarpamp writes: > Any of hundreds of committer and admin accounts could be compromised > with the attacker silently editing the repo. FUD. Committer accounts don't have direct access to the repo. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: fdgrowtable() cleanup
Konstantin Belousov writes: > "Dag-Erling Smørgrav" writes: > > I assume you mean assignments, not calculations. I trust the compiler > > to move them to where they are needed - a trivial optimization with SSA. > It is a dereference before the assignment, so I perceive it as the > calculation. No, I do not think that compiler can move the dereference, > because there are many sequential points between the calculation and > use of the result. Sequence points are a language feature and are only meaningful in the translation phase. Once the code is in SSA form or some other equivalent intermediate representation, the compiler can see that the variables are only used in one specific case and move the assignments inside that block. In fact, it will probably optimize them away, because they are completely unnecessary - I added them solely for readability after Niclas called my attention to the fact that it is almost impossible to understand fdgrowtable() at a first reading. > > Correct, thanks for pointing it out. The easiest solution is to place > > the struct freetable between the file array and the flag array. > As I know, for all ABIs FreeBSD run on, the structure alignment is the > alignment of the most requiring member. You would introduce very tacit > dependency between struct file and struct freetable. The existing code *already* places the struct freetable immediately after the struct file array. What I'm proposing now is to leave the struct freetable where it was but move the fileflags array so they don't overlap. The fileflags array is actually a char[] and has no alignment requirement. Memory usage will not increase, because the code already allocates additional space for the struct freetable to make sure it will fit even if onfiles < sizeof(struct freetable). BTW, I just noticed that there is some dead code in fdgrowtable(): nnfiles = NDSLOTS(nfd) * NDENTRIES; /* round up */ if (nnfiles <= onfiles) /* the table is already large enough */ return; /* ... */ /* allocate new bitmaps if necessary */ if (NDSLOTS(nnfiles) > NDSLOTS(onfiles)) nmap = malloc(NDSLOTS(nnfiles) * NDSLOTSIZE, M_FILEDESC, M_ZERO | M_WAITOK); else nmap = NULL; Since neither nnflags nor onflags are modified between these two chunks of code, the condition in the second if will always be true. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: fdgrowtable() cleanup
Konstantin Belousov writes: > "Dag-Erling Smørgrav" writes: > > + otable = fdp->fd_ofiles; > > + ofileflags = fdp->fd_ofileflags; > These two new calculations could be unused if the function return early. I assume you mean assignments, not calculations. I trust the compiler to move them to where they are needed - a trivial optimization with SSA. > > + ntable = malloc(nnfiles * sizeof(*ntable) + > > + nnfiles * sizeof(*nfileflags) + > > + sizeof(struct freetable), > > M_FILEDESC, M_ZERO | M_WAITOK); > Please use the horizontal space less lavishly. I was aiming for readability, not compatibility with equipment that went out of use before I was born. > I think that this calculation, as well as fo calculation below, does > not take a required alignment of struct freetable into consideration. Correct, thanks for pointing it out. The easiest solution is to place the struct freetable between the file array and the flag array. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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"
fdgrowtable() cleanup
The patch below my signature improves the legibility of fdgrowtable(), and adds comments explaining the hairier bits. The only functional change is that the code no longer overwrites the old fileflags array when the old table is placed on the freelist; instead, it uses the space actually set aside for that purpose. (I assume that the old behavior was harmless, since it has persisted for decades, but it was certainly confusing.) The slightly repetitive nature of the new code is intentional. DES -- Dag-Erling Smørgrav - d...@des.no Index: sys/kern/kern_descrip.c === --- sys/kern/kern_descrip.c (revision 240654) +++ sys/kern/kern_descrip.c (working copy) @@ -148,11 +148,6 @@ #defineNDSLOTS(x) (((x) + NDENTRIES - 1) / NDENTRIES) /* - * Storage required per open file descriptor. - */ -#define OFILESIZE (sizeof(struct file *) + sizeof(char)) - -/* * Storage to hold unused ofiles that need to be reclaimed. */ struct freetable { @@ -1436,7 +1431,7 @@ struct freetable *fo; struct file **ntable; struct file **otable; - char *nfileflags; + char *nfileflags, *ofileflags; int nnfiles, onfiles; NDSLOTTYPE *nmap; @@ -1447,33 +1442,46 @@ /* compute the size of the new table */ onfiles = fdp->fd_nfiles; + otable = fdp->fd_ofiles; + ofileflags = fdp->fd_ofileflags; nnfiles = NDSLOTS(nfd) * NDENTRIES; /* round up */ if (nnfiles <= onfiles) /* the table is already large enough */ return; - /* allocate a new table and (if required) new bitmaps */ - ntable = malloc((nnfiles * OFILESIZE) + sizeof(struct freetable), + /* +* Allocate a new table. We need enough space for a) the file +* entries themselves, b) the file flags, and c) the struct +* freetable we will use when we decommission the table and place +* it on the freelist. +*/ + ntable = malloc(nnfiles * sizeof(*ntable) + + nnfiles * sizeof(*nfileflags) + + sizeof(struct freetable), M_FILEDESC, M_ZERO | M_WAITOK); nfileflags = (char *)&ntable[nnfiles]; + + /* allocate new bitmaps if necessary */ if (NDSLOTS(nnfiles) > NDSLOTS(onfiles)) nmap = malloc(NDSLOTS(nnfiles) * NDSLOTSIZE, M_FILEDESC, M_ZERO | M_WAITOK); else nmap = NULL; - bcopy(fdp->fd_ofiles, ntable, onfiles * sizeof(*ntable)); - bcopy(fdp->fd_ofileflags, nfileflags, onfiles); - otable = fdp->fd_ofiles; + /* copy the old data over and point at the new tables */ + bcopy(otable, ntable, onfiles * sizeof(*otable)); + bcopy(ofileflags, nfileflags, onfiles * sizeof(*ofileflags)); fdp->fd_ofileflags = nfileflags; fdp->fd_ofiles = ntable; + /* * We must preserve ofiles until the process exits because we can't * be certain that no threads have references to the old table via * _fget(). */ if (onfiles > NDFILE) { - fo = (struct freetable *)&otable[onfiles]; + fo = (struct freetable *)(char *)otable + + onfiles * sizeof(*otable) + onfiles * sizeof(*ofileflags); fdp0 = (struct filedesc0 *)fdp; fo->ft_table = otable; SLIST_INSERT_HEAD(&fdp0->fd_free, fo, ft_next); ___ 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: Replacing BIND with unbound
Doug Barton writes: > Dag-Erling, do you have a timeline for getting started on the > ldns/unbound import? I imported the code into the vendor tree, but did not proceed any further as there was still no firm consensus at the time. I believe the conclusion - to the extent that there was one - was that people were fine with tossing out BIND and importing ldns to replace the client bits, as long as we had suitable drop-in replacements for host(1) and dig(1), but there was no consensus on whether to import unbound. I'll start working on getting ldns into head this weekend. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Replacing BIND with unbound
Mark Blackman writes: > drill certainly looks like a drop-in replacement for the common case > as you suggest. But if it's not called 'dig' and I've never heard of > 'drill', I'm unlikely to reach for 'drill', hence the alias > suggestion. I *had* never heard of 'drill' until this thread came up. They are sufficiently similar that writing a wrapper that supports a significant subset of dig's command-line option and uses drill as a backend shouldn't take more than an afternoon for a reasonably experienced programmer. I'm not entirely convinced that it is really required, but considering how easy it would be to implement, there's no reason not to. A drop-in replacement for host is, of course, an absolute requirement. As for nslookup... it's been deprecated for a decade. Its only saving grace is that its interactive mode is useful for playing text adventures implemented with DNS TXT records :) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Replacing BIND with unbound
Mark Blackman writes: > I never use '-t' with dig. drill *told* me I should use '-t' then > completely failed to acknowledge I had done so. > > Marks-Macbook% drill -t www.google.com > [...] > ;; WARNING: The answer packet was truncated; you might want to > ;; query again with TCP (-t argument), or EDNS0 (-b for buffer size) So you got a truncated response and used -t, it didn't help, and drill printed the boilerplate warning message that it always prints when it gets a truncated response. I don't know about you, but I would call that a cosmetic nit. Unless, of course, you had tcpdump running while you did this and it turns out that drill sent a UDP request in spite of -t? It works fine (i.e. it uses UDP by default, and TCP when asked to) for me. I even tried the same nameserver you used, and was very surprised to get an answer. If you know the people who run it, you might let them know that it is inadvisable to process recursive queries from outside their own network. FWIW, the reply I got was not truncated. Perhaps there is a transparent DNS proxy somewhere between you and 178.250.72.130 - quite common with broadband CPE. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Replacing BIND with unbound
Mark Blackman writes: > my DNS resolution is broken, so my ports can't download any tarballs. > In this case, I reach for dig to see which part of the DNS resolution > chain is failing me. > > At the bare minimum, 'dig' should be an alias for 'drill', which I have > to say isn't working brilliantly for me on OS X. It suggests I use '-t' > and then keeps suggesting I use '-t' even when I do use it. > > drill feels a bit rough around the edges to me. This reminds me of the (probably apocryphal) American grade school teacher who complained that the metric system was so inexact; for instance, a meter is _approximately_ a yard, a kilometer is _approximately_ two thirds of a kilometer, etc. By which I mean, of course, that you are blaming drill not for its own shortcomings, but for those of the wrapper you use to _approximate_ dig with drill. The -t option doesn't mean the same for drill as for dig. A proper dig wrapper for drill would have to translate one to the other. However, you should never need the -t option when using dig; I suspect that it exists only for people who are so used to host that they want to use the same command line except for s/host/dig/. Instead of 'dig -t soa des.no', you should use 'dig des.no soa'. The syntax is dig [@server] name [type] [class] I'm not sure why it supports a class argument, since as far as I know, the only class still in use is IN. In the most common case, dig and drill are nearly identical; the command line is exactly the same (except for s/dig/drill/), and the output nearly so - drill doesn't print a question section. If that's a problem for you, it's easily fixed. % dig @ns.des.no des.no soa ; <<>> DiG 9.6.-ESV-R5-P1 <<>> @ns.des.no des.no soa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47226 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; QUESTION SECTION: ;des.no.IN SOA ;; ANSWER SECTION: des.no. 3600IN SOA ns.des.no. hostmaster.des.no. 2012042401 3600 900 360 3600 ;; AUTHORITY SECTION: des.no. 3600IN NS ns.des.no. des.no. 3600IN NS ns.hyp.net. ;; ADDITIONAL SECTION: ns.des.no. 3600IN A 194.63.250.121 ;; Query time: 0 msec ;; SERVER: 194.63.250.121#53(194.63.250.121) ;; WHEN: Mon Jul 9 23:22:05 2012 ;; MSG SIZE rcvd: 128 % drill @ns.des.no des.no soa ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 61642 ;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; QUESTION SECTION: ;; des.no. IN SOA ;; ANSWER SECTION: des.no. 3600IN SOA ns.des.no. hostmaster.des.no. 2012042401 3600 900 360 3600 ;; AUTHORITY SECTION: des.no. 3600IN NS ns.des.no. des.no. 3600IN NS ns.hyp.net. ;; ADDITIONAL SECTION: ns.des.no. 3600IN A 194.63.250.121 ;; Query time: 0 msec ;; SERVER: 194.63.250.121 ;; WHEN: Mon Jul 9 23:22:23 2012 ;; MSG SIZE rcvd: 128 DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Replacing BIND with unbound
Gabor Kovesdan writes: > Other than the functionality, when we replace something, it is also > important to do some benchmarks and assure that the performance is not > reasonably worse. Some time back I committed the error of not > carefully pass this requirement with BSD grep but so far it seems it > went fine with the recent BSD sort change. It would be nice to also > ensure this with the unbound change if it really happens. What sort of benchmarks do you envision? Unlike named, unbound is intended to serve only one client (localhost) or a small number of clients (a SOHO). With that kind of load, one could be ten times slower than the other and you wouldn't notice, because other factors, like network latency, completely dwarf the time the nameserver itself spends servicing a request. (note that I fully expect unbound to hold its own on corporate networks with thousands of clients, but I doubt my boss is going to let me run performance comparisons on the university's network) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Replacing BIND with unbound
Avleen Vig writes: > As bind-tools and BIND (the resolver) as separate, why not just leave > bind-tools in base? They'll work happily with unbound. The bind-tools (host, dig, nslookup) are command-line frontends for the resolver. Perhaps what you are trying to say is that they are separate from the authoritative nameserver (named). Yes, they are, but they have a *lot* of code in common. In fact, *most* of the code in BIND is common code shared between named, dig etc. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Replacing BIND with unbound
Avleen Vig writes: > It would be silly not to keep bind-tools in base. `host` and `dig` are > very standard tools most people expect to be available in base, just > as they are in the base/core/whatever of other operating systems. We should definitely have an implementation of host(1), but dig(1) is not nearly as widely used, and ldns's drill(1) supports the same command-line syntax for the most common operations. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Pull in upstream before 9.1 code freeze?
Doug Barton writes: > The correct solution to this problem is to remove BIND from the base > altogether, but I have no energy for all the whinging that would happen > if I tried (again) to do that. I don't think there will be as much whinging as you expect. Times have changed. I'm willing to import and maintain unbound (BSD-licensed validating, recursive, and caching DNS resolver) if you remove BIND. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Pull in upstream before 9.1 code freeze?
Robert Simmons writes: > OpenSSH 6.0p1 No. It doesn't build cleanly on FreeBSD (I reported two issues during the pre-release cycle, one was fixed but the other was not), and even if it did, it's too big a change to push through on such short notice. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Does anyone use nscd?
Michael Bushkov writes: > 2. Consequences of the aforementioned problem can probably be > corrected by using _setsockopt(..., SO_NOSIGPIPE) in > __open_cached_connection() in nscachedcli.c That sounds like a workaround rather than a fix... DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Does anyone use nscd?
"Daniel O'Connor" writes: > I'd be interested in testing your workaround(s) :) It wasn't a workaround, actually, just a one-line change that enables additional logging (when running with from the console -nst) which might help me figure out why it crashes. See my reply to Artem Belevich earlier in this thread. While we're at it, I'd be very grateful if someone could email me a quick and dirty guide to setting up an LDAP server for testing. I have too much on my plate right now to start reading documentation... DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Does anyone use nscd?
Lawrence Stewart writes: > If the machine running nscd loses connectivity with the DNS server for > a while and does a DNS lookup during that time, nscd will cache the > -ve reply indefinitely for all users, which breaks all sorts of > crap. Have to forcibly run "nscd -I all" to fix. I will find and fix > this bug one day if noone beats me to it... Definitely a bug, nscd is only supposed to cache negative responses for 60 seconds. I hope you find the time to track it down :) Is it 100% reproducable? How long does the DNS server have to be unreachable before it happens? > I'd like to see it stay in base. Moving it (slowly) towards a point > where we can turn it on by default would be cool. Agreed, in principle. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Does anyone use nscd?
Samuel Martín Moro writes: > Using it since a few, almost without any problem. Just one thing: > while connected to some external intranet, nscd still try to contact > my LDAP. Well, by default, nscd caches hits for an hour and misses for a minute. One could imagine an option to have nscd return the cached entry if it can't contact the server, even if it has technically expired, but the problem is that nscd doesn't know what the backend is and can't reliably tell whether the lookup failed because the server is unreachable or just because the entry does not exist; and even if it could, it would still have to query the backend every time, so you might still get a longish timeout for every lookup, depending on the type of backend and the reason it failed. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Does anyone use nscd?
Artem Belevich writes: > And I do have a way to reproduce the SIGPIPE problem. Populate ~30K > entries in NIS passwd database, enable nscd and then run top. In my > case top used to die with SIGPIPE pretty reliably. I've fixed the > issue locally by setting SO_NOSIGPIPE on the socket in > __open_cached_connection() in lib/libc/net/nscachedcli.c and I've been > running with the fix for few months now. Any chance of getting a backtrace from an unpatched nscd? Ideally with the change described here: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/136073#reply1 To test, stop nscd, then run it from the command line like so: $ su - # cd /tmp # ulimit -c 0 # /usr/sbin/nscd -nst (do something in another terminal that causes it to crash) # echo backtrace | gdb -batch -x /dev/stdin /usr/sbin/nscd nscd.core and send me the output from both nscd and gdb once it crashes. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Does anyone use nscd?
Trond Endrestøl writes: > It's in daily use at Gjøvik Technical College (Fagskolen i Gjøvik), > here in Norway. Both the mail and web servers authenticates our users > by LDAP, and nscd certainly speeds up the lookups. OK. No trouble with clients dying of SIGPIPE? I could never reproduce the bug, but both users who reported problems used ldap, and I don't have an LDAP server to test against, so I thought it might be specific to LDAP. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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"
Does anyone use nscd?
Does anyone actually use nscd? I ask because when I cleaned up a slew of aliasing bugs a couple of years ago, I believe I may have introduced a bug; I got exactly two complaints, and neither of the complainants could be bothered to try the workaround I suggested and report back. Although the code quality is atrocious, nscd is actually a pretty good idea. I suspect the reason why nobody uses it is that it's off by default and people simply don't know about it. Besides nuking it, which would be a shame, we have a range of options, from "just fixing the bug so those who want to use it can" in one end to "finding someone willing to clean it up and maintain it and enable it by default" in the other. (no, I'm not volunteering to maintain it) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: setting a random password with PAM API
"Christopher J. Ruwe" writes: > I am trying to implement the feature to set a random password like in > BSD "pw usermod -W" in the Solaris passwd. Regrettably, I have not > found or perhaps not understood the PAM API documentation on how to > _inject a given string_ into the change-auth-token function > pam_chauthtok(...), which always jumps in an interactive pw-changing > loop. There is no reliable way to do that. You don't even know that there is such a thing as a password. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: IPSEC allegations
[redirected from -hackers to -security] Jakub Lach writes: > http://marc.info/?l=openbsd-tech&m=129236621626462&w=2 http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-ipsec-backdoor-allegations.html DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: coretemp(4)/amdtemp(4) and sysctl nodes
Mark Johnston writes: > Aren't the dev.cpu.X and the coretemp sysctls matched up by the use of > > SYSCTL_CHILDREN(device_get_sysctl_tree(pdev)) > > in coretemp's sysctl definition? What does the sysctl context have to do > with identifying the parent oid? They're intended to go hand in hand. I would have preferred that contexts were actually tied to subtrees, but I had to play the ball I was given. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: coretemp(4)/amdtemp(4) and sysctl nodes
m...@freebsd.org writes: > Each device provides a device_get_sysctl_ctx sysctl_ctx that is > automatically cleaned up when the device goes away. Yet the sysctl > nodes for both amdtemp and coretemp use the context of other devices, > rather than their own. I can't quite figure out why, though the two > are slightly different enough that they may have different reasons. I can't speak for amdtemp, but if coretemp used its own context instead of its parent's context, it would show up as dev.coretemp.X.temperature instead of dev.cpu.Y.temperature, where X is not necessarily equal to Y. Since, as you point out, the coretemp device is a child of the corresponding cpu device, there is no risk of orphaning the temperature OID. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: find(1): Is this a bug or not?
Bakul Shah writes: > "Dag-Erling Smørgrav" writes: > > You should replace the err() call with a warn() call instead of > > removing it outright. > That would print the err msg twice as opendir (or something) already > seems to report the error. Try it! Oh, OK. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: find(1): Is this a bug or not?
Bakul Shah writes: > Index: function.c > === > --- function.c (revision 212707) > +++ function.c (working copy) > @@ -560,7 +560,7 @@ > empty = 1; > dir = opendir(entry->fts_accpath); > if (dir == NULL) > - err(1, "%s", entry->fts_accpath); > + return 0; > for (dp = readdir(dir); dp; dp = readdir(dir)) > if (dp->d_name[0] != '.' || > (dp->d_name[1] != '\0' && You should replace the err() call with a warn() call instead of removing it outright. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Unhappy with cross-worlding
rank1see...@gmail.com writes: > After I've created, bootable binary USB amd64 on i386, I wanted do a > freebsd-update, on memstick, via '-b' flag, to avoid doing it later. > > Conclusion: > Don't use '-b' at all, as it fetches updates for LOCAL running OS > (i386) Well, yes. That's what it's for. It was never meant for cross- upgrades. You can fool it by setting the correct UNAME_* envars, though, if you know what you're doing, but that's not how it's intended to be used. > This cross-worlding is a total mess! > Nothing works. Nothing that you've tried works because everything you tried was wrong. You can't just make something up and expect it to work because you want it to work. Read the documentation and use the proper tool for the proper job. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Unhappy with cross-worlding
Julian Elischer writes: > Garrett Cooper > > But yes, building amd64 on i386 probably won't work too well :)... > It's supposed to but hasn't for years. Umm, what do you mean? You can cross-build world and kernel with TARGET=amd64 (this is what the tinderbox and 'make universe' do), then install the kernel, reboot into single-user mode, and install world. Some things won't work properly until you've built and installed world a second time, but nothing important AFAIK. You may have to copy /libexec/ld-elf.so.1 to /libexec/ld-elf32.so.1 before you reboot - it used to be necessary, but ISTR someone hacked around it to make it easier to run 32-bit chroots on amd64. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: dump cache performance
Peter Jeremy writes: > Dag-Erling Smørgrav wrote: > > 9413 what? Puppies? > Ooops, sorry - KB/sec as reported in the dump summary. Thank you :) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: dump cache performance
Peter Jeremy writes: > I've mostly convered to ZFS but still have UFS root (which is basically > a full base install without /var but including /usr/src - 94k inodes > and 1.7GB). I've run both the 8-stable ("stable") and patched ("jfd") dump > alternately 4 times with 50/250MB cache with the following results: > > x stable > + jfd > ++ > | +| > | +| > | x+| > |x xx +| > ||AMA| > ++ > N Min MaxMedian AvgStddev > x 4 9413 9673 95689555.5 107.12143 > + 4 15359 15359 15359 15359 0 9413 what? Puppies? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Summary: Re: Spin down HDD after disk sync or before power off
Bruce Cran writes: > The Ubuntu issue was what I was thinking of - I got that mixed up with > the aggressive power management of the WD EARS drives. The entire Green series, actually, which includes models such as the EADS, AARS etc., but there's more to them than that - the central feature is their dynamically adjusted rotational speed, which allows them to conserve power without spinning all the way down. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Summary: Re: Spin down HDD after disk sync or before power off
RW writes: > Alexander Best wrote: > > this seems to indicate that spinning down a disk has quite an impact. > That's mostly likely a hang-over from older disk technologies when the > heads touched the surface on spinning down. They still do, although these days the "landing zone" has a special surface designed to minimize friction on the head and prevent it from sticking to the surface. In addition, in an emergency unload (when power is lost while the disk is still spinning) the heads retract in a violent and uncontrolled manner, which can lead to mechanical damage to the arms. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Summary: Re: Spin down HDD after disk sync or before power off
Alexander Best writes: > no need to get upset. you asked where i found the information regarding the > wear impact of spinning down disks and i gave you the answer. I am upset by your claim that "doing spin downs upon reboot might be even worse than not doing spindowns upon shutdown", because you should know better, and following your advice could damage people's hardware. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Summary: Re: Spin down HDD after disk sync or before power off
Bruce Cran writes: > Do we think our users are silly enough to set a short timeout of just a > few minutes? I'd think most would use a setting of 20-30 minutes at > a minimum. I never did understand why there were so many warnings; > after all, some laptops even come with a default APM scheme in their > HDDs that powers the disk down after 7 seconds! Really? That would make the system close to unusable, and the disk's life expectancy would be reduced to a few months; a disk that performs two load / unload cycles per minute on average will need replacing after three to six months. Remember, there was a huge flap a couple of years when Ubuntu shipped with a default timeout of 90 seconds, which is more than ten times more than what you suggest. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Summary: Re: Spin down HDD after disk sync or before power off
Alexander Best writes: > Dag-Erling Smørgrav writes: > > No. Where did you get that idea? To repeat what I've said before - > > several times - in this thread, a modern disk drive can handle hundreds > > of thousands of controlled unloads but only a few hundred emergency > > unloads. Given the choice between "never spin down" and "always spin > > down", the safe alternative is "always spin down". > atacontrol(8) says that: > > "You should not set a spindown timeout on a disk with / or syslog logging > on it as the disk will be worn out spinning down and up all the time." > > this seems to indicate that spinning down a disk has quite an impact. The problem with setting a short idle timeout is that, on a typical laptop or desktop system, you end up spinning the disk down and back up several hundred times a day, which increases power consumption, I/O latency and wear. However, a single emergency unload (what happens when the disk loses power without first unloading the head) shortens the disk's life expectancy as much as hundreds or thousands of controlled unloads. Unless you think our users commonly reboot their computers hundreds or thousands of times between each time they cycle the power, the safe alternative is to *always* spin down during shutdown. I truly hope this is the *last* time I have to repeat this. It's really not that hard to understand. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Summary: Re: Spin down HDD after disk sync or before power off
Alexander Best writes: > since there seems no way to distinguish between these two states in ATA(4) > it's > probably better to leave it as it is, since doing spin downs upon reboot might > be even worse than not doing spindowns upon shutdown. No. Where did you get that idea? To repeat what I've said before - several times - in this thread, a modern disk drive can handle hundreds of thousands of controlled unloads but only a few hundred emergency unloads. Given the choice between "never spin down" and "always spin down", the safe alternative is "always spin down". DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Why is TUNABLE_INT discouraged?
Garrett Cooper writes: > PS I added uquad_t for consistency in the APIs, even though quad_t was > deprecated, but I didn't bump __FreeBSD_version__ -- wasn't sure if I > should have done that). You should bump __FreeBSD_version__ anyway so third-party or shared code can use the new API if it is available and the old one if it isn't. > Let's try with the patch attached... Mailman strips binary attachments. The correct MIME type is text/x-patch. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Summary: Re: Spin down HDD after disk sync or before power off
Garrett Cooper writes: > Agreed. Spinning down at reboot isn't smart and seems like a good way > to kill a disk quicker. *not* spinning down at halt is far worse. Most modern disks are rated for hundreds of thousands of load-unload cycles, but far fewer emergency unloads (which is what happens when the drive loses power while still spinning). DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: expand_number() for fetch'es -B and -S switches
Alexander Best writes: > Dag-Erling Smørgrav writes: > > Alexander Best writes: > > > so how about forgetting about expand_number() and simply > > > introducing a maximum buffer size of 1 megabyte? > > so how about just leaving the code alone? :) > i thought you wanted to have a maximum buffer size of 1MB in fetch? Yes, I was just commenting on the highly roundabout way we followed only to end up almost at the status quo. > right now -B can be any value and it's quite easy to trigger ENOMEM. "don't do that, then!" My suggestion is that if you're going to change it at all, use expand_number() *and* limit it to 1 MB. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: expand_number() for fetch'es -B and -S switches
Alexander Best writes: > so how about forgetting about expand_number() and simply introducing a > maximum buffer size of 1 megabyte? so how about just leaving the code alone? :) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: expand_number() for fetch'es -B and -S switches
Alexander Best writes: > the current maximum buffer limit of fetch(1) actually is around 1G. i > think 1M is not enough, because if people are pulling data over fast > lines they'll have almost constant disk writes. how about 100M then? > ;) Large buffer sizes are *not* better, since fetch(1) will alternate between filling the buffer and writing it to disk. The buffer should not be too small, but it should not be too large either; the sweet spot is somewhere around 128 kB. > on the other hand why have a maximum limit? if people want to have a > buffer of 100 gigabyte why shouldn't they? it's their decision > actually. Good point... although if they set it too high, either malloc(3) will fail - if they're lucky - or fetch(1) will crash when the system runs out of physical RAM and swap, and they'll have to start over. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: expand_number() for fetch'es -B and -S switches
Alexander Best writes: > so how about something like this? the fetch(1) manual would have to be changed > a bit to state that if '-B val' > 1G it silently gets set to 1G. 1 GB is ridiculously large. 1 MB should be plenty. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: /stand/camcontrol
Xin LI writes: > Dag-Erling Smørgrav writes: > > Xin LI writes: > > > My 2 cents: I think we don't really need to care about the size > > > for rescue binary after the splitfs VFS layer have been introduced > > > to libstand? Build of release split MFSROOT was 2006-ish and I > > > feel that this can be gone. > > This is /stand, not /rescue; /rescue has a full camcontrol. > Oh you are right. But MFSROOT have /stand (for sysinstall), not > /rescue, I think? Correct. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: expand_number() for fetch'es -B and -S switches
Alexander Best writes: > since you're the originator of fetch(1): should i send you a patch to add > expand_numer() to the -B switch or do you think fetch is better off as it is > now without humanised numbers? Sure, but we need to commit the expand_number() patch first. > i'm not sure, but i think fetch(1) is BSD specific so no POSIX regulations > need > to be taken into consideration. but you probably know more about this matter. fetch(1) is 100% home-grown. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Support for WD Advanced Format disks
"Andresen, Jason R." writes: > Dag-Erling Smørgrav writes: > > I see no reason why sector size should be a selection criterium. Just > > buy the disk that gives you the best performance and / or capacity for > > your money. WD Green disks are cheap, but other vendors offer models > > with the same capacity and twice the speed for only 5% or 10% more. > Heck, Western Digital themselves offer faster drives that are only a > few dollars more. Yes, the blue series IIRC. I was looking at Caviar Black prices, which are significantly higher. > The Green drives are built for low noise/power/heat, not for speed. Yup. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: /stand/camcontrol
Xin LI writes: > My 2 cents: I think we don't really need to care about the size for > rescue binary after the splitfs VFS layer have been introduced to > libstand? Build of release split MFSROOT was 2006-ish and I feel that > this can be gone. This is /stand, not /rescue; /rescue has a full camcontrol. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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"
/stand/camcontrol
Consider the following commit: r89471 | joerg | 2002-01-17 21:26:14 +0100 (Thu, 17 Jan 2002) | 8 lines Provide an option to make camcontrol `minimalistic': if the (env/make) variable RELEASE_BUILD_FIXIT is defined, a camcontrol binary will be built that only knows the "rescan" and "reset" subcommands. The resulting code is small enough to still fit onto the boot floppy. This makes /stand/camcontrol completely useless. Do we still care about fitting sysinstall on a floppy? The full camcontrol is about 100 kB larger than the pared-down version, but I'm not sure the difference is that big when it's crunched with the rest of /stand. textdata bss dec hex filename 268751 26464 54112 349327 5548f camcontrol-crunch 355122 27064 58904 441090 6bb02 camcontrol-full DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: expand_number() for fetch'es -B and -S switches
Alexander Best writes: > just having a quick look around to see, if anybody would be interested in > fetch -B and fetch -S accepting humanized numbers using expand_number()? I can understand it for -B, but not for -S, since in the common case (by 1023 to 1, assuming a random distribution) the argument to -S can not be expressed in [kMGTEP]B. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Support for WD Advanced Format disks
Ilya Bakulin writes: > May you suggest any other tests? What other tests? The disks suck, how are more tests going to improve the situation? > Or let's live with sucking WD Green and look for other 4096K-sector > models from other manufacturers? I see no reason why sector size should be a selection criterium. Just buy the disk that gives you the best performance and / or capacity for your money. WD Green disks are cheap, but other vendors offer models with the same capacity and twice the speed for only 5% or 10% more. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Support for WD Advanced Format disks
Ilya Bakulin writes: > Dag-Erling Smørgrav writes: > > Why did you shift the gnop? Did you short jumper 7-8? > No, 7-8 remained as-is. ad7p1 was created using: > #gpart add -t freebsd-ufs -s 10G -b 63 ad7 > > So it begins at sector #63, but physical 4096-block begins at logical > sector 64. That's why I shifted gnop by 1 sector. Why aren't you using the whole disk? > > Yes. WD Green disks suck. > Is it a problem of WD Green or it is common to all 4096-sector models? WD Green, even their non-AF disks (like the WD20EADS I tested) suck. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: hexdump(1)/od(1) skip function off-by-one when offset == file length
Alexander Best writes: > *hehehe* that might be true. maybe they've bought the src from AT&T? anyway i > don't think the BSD license restricts you releasing code under a new license. > so what they did seems fine to me. You can release the code under a different license, but you still have to include the original license, disclaimer and copyright statement. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Support for WD Advanced Format disks
Thiago Damas writes: > "ATA 4K sector issues" > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-March/031154.html Yes, we know. That's what this entire thread (and a zillion others before it) is about. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Support for WD Advanced Format disks
Ilya Bakulin writes: > So, ad7p1.nop is shifted by 512 bytes and resides right on the > beginning of the physical sector. And it has 4096 "sector" size. Why did you shift the gnop? Did you short jumper 7-8? > For some reason, phybs begins with sector size 8192... I expected it > to begin with 4096... It starts at 2 x reported sector size, because it is designed primarily to test alignment, not performance. > Perfomance is excellent! No, performance blows. See here: http://maycontaintracesofbolts.blogspot.com/2010/08/benchmarking-advanced-format-drives.html > Notice, that for two subsequent phybs invocations there is big > difference in timings for the same parameters. Yes. WD Green disks suck. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Winbond Watchdog
"Daniel O'Connor" writes: > They're LPC ISA devices, I don't know if they appear in any PNP or > ACPI tables though. Same issue with ichwd: ISTR there is actually supposed to be an entry for it in an ACPI table, but on the motherboard I had when I tested it before I committed it, that table either did not exist or was empty. That was three years ago, though, so my recollection is a bit fuzzy. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Support for WD Advanced Format disks
jhell writes: > On stable/8 this is needed to build. Seems the need for linking against > libutil came in revision r211233. Yes, I forgot to commit the Makefile. Thank you for reminding me. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Why is TUNABLE_INT discouraged?
Garrett Cooper writes: > Dag-Erling Smørgrav writes: > > It might be a good idea to introduce TUNABLE_POINTER and TUNABLE_SIZE. > I would actually argue against doing that because it would only create > divergence between sysctl and tunable KPIs... Not if we also introduce corresponding SYSCTLs. Note that my idea is to have these as aliases for the correct primitive types. > (BTW, when you say TUNABLE_SIZE, I assume it would be a size_t quantity?) Yes. > Something might need to be done to the values returned by the tunables > though, because they don't respect boundaries, and can overflow right > now (which exacerbates the issue with values crammed into smaller > datatypes)... Yes. How about this: - rename getenv_quad() to getenv_signed() and getenv_unsigned() - add min / max arguments - implement getenv_quad() (and all the others) in terms of getenv_number() e.g. int getenv_uint(const char *name, unsigned int *data) { unsigned long long tmp; int rval; if ((rval = getenv_unsigned(name, &tmp, 0, UINT_MAX)) == 0) *data = (unsigned int)tmp; return (rval); } (note that due to the min / max arguments, the complexity of handling both signed and unsigned values in the same function probably exceeds the complexity of having two very similar functions) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Support for WD Advanced Format disks
Matthew Jacob writes: > Yes, that should be it! No, it shouldn't, cf. extensive discussion about EARS disks on -current. They lie about their physical sector size. There's a jumper setting for "Windows XP compatibility", but apparently, it only affects the (fake) geometry the disk reports to the BIOS. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Support for WD Advanced Format disks
Bakul Shah writes: > After poking around some, it seems ATA/ATAPI-7 Identify Device word > 106 bit 13 is set to 1 and bits 0-3 are set to 3 (for 2^3 or 8 LBAs > per sector) for a 4KB sector size (pin 7-8 jumper on a WD AF disks > presumably changes this setting to 0,0). See page 121 of Atapi-7 > volume 1 (google for ata-atapi-7.pdf). Yes. We already support this. The problem is that WD's Advanced Format disks (or at least some of them) lie. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Support for WD Advanced Format disks
Bakul Shah writes: > http://www.wdc.com/en/library/2579-001028.pdf gives an > explanation of what the drive letters mean but they don't > talk about 4k sector size. The latest data sheet for the entire Green series is here: http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701229.pdf > Some models of the WD Caviar Green and WD Scorpio Blue > product families are built using Advanced Format technology. > Over time more models and capacities will be added. WD drives > with Advanced Format technology include special installation > information on the drive label so be sure to read the label > on your drive before installing it. ^^ > ^^^ > > So it seems that only the label distinguishes 4k sector drives. The data sheet clearly says that *only* AARS and EARS disks are AF. Also, it's not just the label - AF disks have AF-specific jumper settings. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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"
Support for WD Advanced Format disks
I'm looking into a clean, permanent solution for WD Green drives that use 4096-byte physical sectors. To summarize the information I've collected so far: - There are several types of WD Green disks. I am primarily interested in the 1+ TB models: EARS and EADS. - According to WD's own documentation, EARS disks are Advanced Format while EADS disks are not; furthermore, EARS disks have 64 MB cache while EADS disks have only 32 MB. - There is at least one source that provides model and serial numbers for two EADS disks that seem have the performance characteristics of an Advanced Format disk. One of them actually reports 4096-byte sectors, the other does not. I am not entirely certain that source is reliable. - Advanced Format disks should have a label that clearly describes them as such: http://media.bestofmicro.com/U/O/238272/original/Western-Digital-WD10EARS-top.jpg - I received an EADS disk and performed measurements which clearly show that it is *not* an Advanced Format disk. I had no trouble achieving 50 MBps with misaligned 8192-byte writes. Right now, I have two requests. The first is that people who have Advanced Format disks run a program I wrote that measures the performance of aligned and misaligned writes of different sizes. % svn co http://svn.freebsd.org/base/user/des/phybs % cd phybs % make % ./phybs -w /dev/adN Please note: - This test is *destructive*. Do not run it on a disk that contains data you care about; it *will* destroy them. - You can not run it on a file, but you *can* run it on a partition instead of the whole disk. You can even run it on a misaligned partition; the results will show by how much the partition is misaligned. - The test takes a long time. It took about half an hour on a WD20EADS connected by eSATA. It may take several hours on an Advanced Format disk. If you are impatient, try bumping MINSIZE to 1024 in phybs.c. The second request is for some kind soul to send me an EARS drive to play with; please contact me off-list if you're interested. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: glabel "force sectorsize" patch
Ivan Voras writes: > Dag-Erling Smørgrav writes: > > Marius Nünnerich writes: > > > I did not think of a new GEOM class that looks like glabel but one > > > that has no metadata stored on disk . It is then activated and > > > controlled by loader.conf variables. (Maybe like gnop? If I > > > remember correctly, I did not take a look at that class for ages). > > As you would know if you had followed the discussion about WD EARS > > disks, gnop does what you want and is currently the recommended > > solution. > Of course, but gnop as a testing GEOM class, does not save its > metadata, meaning it has to be reconfigured after reboot, etc. Please read what Marius wrote, which I quoted above. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: glabel "force sectorsize" patch
Marius Nünnerich writes: > I did not think of a new GEOM class that looks like glabel but one > that has no metadata stored on disk . It is then activated and > controlled by loader.conf variables. (Maybe like gnop? If I remember > correctly, I did not take a look at that class for ages). As you would know if you had followed the discussion about WD EARS disks, gnop does what you want and is currently the recommended solution. I am looking into a permanent solution and would appreciate if people held off on this for a couple of weeks. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Why is TUNABLE_INT discouraged?
Garrett Cooper writes: > Why would someone express a tunable in a memory address (not being > sarcastic... I just don't see why it makes sense right now, but if > there's a valid reason I'm more than happy to be educated :)..)? A few examples: hw.acpi.host_mem_start hw.pci.host_mem_start hw.physmemstart The following are not addresses, but can be > 32 bits on 64-bit machines and even on some 32-bit machines using PAE / PTE: hw.physmem vm.kmem_size vm.kmem_size_max vm.kmem_size_min It might be a good idea to introduce TUNABLE_POINTER and TUNABLE_SIZE. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Why is TUNABLE_INT discouraged?
Ivan Voras writes: > Dag-Erling Smørgrav writes: > > Not sure what you mean. The original issue was that someone had used > > TUNABLE_INT() for something that was actually a memory address. I > > changed it to TUNABLE_ULONG(). Of course, if your tunable is a boolean > > value or something like maxprocs, an int is fine - but so is a long. > Semantically valid but using TUNABLE_INT to hold pointers is a > developer bug, not the fault of the API, and there's nothing wrong > with "int" as a data type in this context. That's the point. There was no TUNABLE_ULONG() at the time. I added it to fix the bug. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Why is TUNABLE_INT discouraged?
Garrett Cooper writes: > Dag-Erling Smørgrav writes: > > Perhaps. I don't remember all the details; I can't find a discussion in > > the list archives (other than me announcing the change in response to a > > bug report), but there must have been one, either on IRC or in Karlsruhe. > > In any case, I never removed TUNABLE_INT(), so... > It does matter for integers on 64-bit vs 32-bit architectures though, > right Not sure what you mean. The original issue was that someone had used TUNABLE_INT() for something that was actually a memory address. I changed it to TUNABLE_ULONG(). Of course, if your tunable is a boolean value or something like maxprocs, an int is fine - but so is a long. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Why is TUNABLE_INT discouraged?
Ivan Voras writes: > Ok, but still - if the underlying value really is declared as "int", > doesn't it make perfect sense to have something like TUNABLE_INT for it? Perhaps. I don't remember all the details; I can't find a discussion in the list archives (other than me announcing the change in response to a bug report), but there must have been one, either on IRC or in Karlsruhe. In any case, I never removed TUNABLE_INT(), so... DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Why is TUNABLE_INT discouraged?
Garrett Cooper writes: >I found the commit where it was made (by des@ -- cvs revision > 1.120), but unfortunately I lack the context as to why that suggestion > is made; the commit isn't very explicit as to why integers tunables > should be discouraged You're supposed to use TUNABLE_LONG or TUNABLE_ULONG instead. From digging in the -current archives, it seems that the motivation was a bug that resulted from using a TUNABLE_INT for a value that was actually an address. It was doubly broken: first because it was too small on 64-bit systems, and second because it was signed. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Winbond Watchdog
Xin LI writes: > I'm still polishing up the driver, there seems to be no way to figure > out the base port address directly (datasheet said it's either 0x2e and > 0x4e) so for now I have its device identify method to do some dirty > hacks (outb/inb directly) and only check if with appropriate key entered > to the port we will get non-0xff value. Sounds gross, but if there's no other way, I guess it'll have to do. I imagine you check the PCI id etc. first? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Using lex in a shared library
Not related to your problem, but related to $SUBJECT: make sure to use -P in LFLAGS so your lex-generated symbols don't conflict with those present in applications that use your library, or in other libraries those applications may use. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Supermicro BIOS's watchdog feature?
Xin LI writes: > "Dag-Erling Smørgrav" writes: > > Perhaps the motherboard has additional watchdog hardware? If you > > disable the watchdog in BIOS, does ichwd still work? > If I kill -9 watchdogd the system do reset itself so I think ichwd(4) > really works even if BIOS setting is 'Disabled' (but I'm not sure if > this method is right? Looking at the code I think the answer is > probably "Yes" though) Yes. This confirms my hypothesis, which is that your motherboard has additional watchdog hardware, and that the BIOS setting controls that, not the ichwd watchdog timer. Just disable the watchdog in BIOS and use ichwd instead. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Supermicro BIOS's watchdog feature?
Xin LI writes: > Hmm... Sorry I think I didn't described the behavior accurately. > Currently if I enable the "Watch Dog" option in BIOS, the system > reboots after ~5 mins regardless whether I have ichwd(4) and > watchdogd(8) loaded. Perhaps the motherboard has additional watchdog hardware? If you disable the watchdog in BIOS, does ichwd still work? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Supermicro BIOS's watchdog feature?
Matthew Jacob writes: > Xin LI writes: > > It seems that ICH10R's watchdog is supported by ichwd(4) but > > Supermicro BIOS needs some special treatments which is beyond what > > ichwd(4) and watchdogd(8) would do... > What do mean "special" treatment? The watchdog timer can be disabled in hardware (by pulling the speaker pin high during boot, IIRC). Even if it is enabled, it can be caught and ignored by the SMM firmware. Some BIOSes have options to enable or disable the watchdog timer, which I assume means that they flip a bit that tells the firmware to either catch it or pass it through. Unfortunately, although it is possible for the ichwd driver to detect programatically (by checking an MSR) if the watchdog timer is disabled in hardware, it is not possible to determine whether it is disabled in firmware. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Help with some makefile hackery
Patrick Mahan writes: > Maybe I should do this instead? > > src-kernel: src-kernel-tools > cd src; ./amd64-kernel.sh 2>&1 > build_amd64_kernel.log; \ > tail -f build_amd64_kernel.log > > It is not too clear if the status is the last one in a compound > command. This won't work, because tail won't start until the build is done. You should just pass the file name as an argument to your script and handle it there. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Help with some makefile hackery
Patrick Mahan writes: > In the top-level makefile I have the following label: > > src-kernel: src-kernel-tools > cd src; ./amd64-kernel.sh 2>&1 | tee build_amd64_kernel.log > > If there is a build failure with the kernel, it can be seen in the > file 'build_amd64_kernel.log'. However, the top-level make file just > continues on to the next label as if no error occurs. Make looks at tee's exit status, not the script's. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: using cupsd instead of base lpr
Ed Schouten writes: > In my opinion, we should just rename mailwrapper to whateverwrapper > and list the lpr programs in there as well. Take a look at /etc/alternatives in any Debian-based Linux distro... DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
Andriy Gapon writes: > Yes, you are absolutely correct. This comes from the fact that amd64 uses > simple > objects files (aka .o) as kernel modules and i386 uses full-blow dso. The obvious question is: since, as I understand, amd64's solution is superior, what would it take to switch to .o on other platforms? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Help with some makefile hackery
Patrick Mahan writes: > My issue is that if there is a build failure at any point, the > status does not seem to be propagated upward. For example, if > the kernel fails to build due to incorrect code, the script > -kernel64.sh stops (verifable by examining the logfile), > however, the make will continue to the next target, src-world, > and continue building. How do I propagate the status up to the > top-level make? Your shell script needs to exit with a non-zero status if it fails. There are several ways to do this. For instance, if your shell script looks like this: #!/bin/sh make TARGET=amd64 kernel-toolchain you can: - prefix "make" with "exec": sh will exec make instead of running it in a subshell, and the exit status will be whatever make returns. - add the following line at the bottom: exit $? which causes the shell script to exit with the same exit status as the last command it ran, in this case make. - append "|| exit 1" to the the "make" command line; this will cause the script to exit immediately with status 1 if make fails, otherwise it will continue (in case you want to do something else if make succeeds) - wrap the make command line in an if statement, which allows you do additional work depending on the outcome, and end the failure case with "exit 1" or similar - insert the following line at any point between the shebang and the make command line: set -e this will cause sh to terminate the script immediately with a non-zero exit status if any command after the "set" line fails. However, I don't see the point of using shell scripts in the first place... DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: head behaviour
Bakul Shah writes: > Except read doesn't do it quite right: > > $ ps | (read a; echo $a ; grep zsh) > PID TT STAT TIME COMMAND yeah, I forgot that it drops leading whitespace... DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: head behaviour
Doug Barton writes: > If you have a 2 line file named foo that looks like this: > one > two > > Then do: cat foo | (cat ; echo 'blah' ; cat) > > you get: > one > two > blah > > > which seems to indicate to me that unless the first command is a shell > builtin that the first command is going to receive all of the stdin, > and the second command none of it. The second command will receive whatever is left after the first is done. Otherwise, read(1) loops wouldn't work. You chose a poor example, since cat(1) consumes *everything*. Try using dd(1) instead, with varying block sizes and counts: /usr/src/sys% ls | (dd bs=32 count=1 ; echo "** hello **" ; dd bs=32 count=1) Makefile amd64/ arm/ boot/ bsm/ 1+0 records in 1+0 records out 32 bytes transferred in 0.000156 secs (204913 bytes/sec) ** hello ** cam/ cddl/ compat/ conf/ contrib1+0 records in 1+0 records out 32 bytes transferred in 0.000134 secs (238822 bytes/sec) The reason why head(1) doesn't work as expected is that it uses buffered I/O with a fairly large buffer, so it consumes more than it needs. The only way to make it behave as the OP expected is to use unbuffered I/O and never read more bytes than the number of lines left, since the worst case is input consisting entirely of empty lines. We could add an option to do just that, but the same effect can be achieved more portably with read(1) loops: % nhead() { for n in $(jot $1) ; do read line ; print $line ; done } % jot 15 | (nhead 5 >/dev/null; nhead 3; echo hi; nhead 3) 6 7 8 hi 9 10 11 DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: head behaviour
Doug Barton writes: > Bakul Shah writes: > > $ ps|(head -1; grep sh) > >PID TT STAT TIME COMMAND > I don't understand why you think this would work. There is no input to > the grep command. The only reason it exits at all is that you are > executing in a subshell. The output from ps is piped to the subshell, so all processes within that subshell get their stdin from that output. Bakul's error is in assuming that head will *consume* only the first line of input, whereas the only guarantee actually given is that it will *print* only the first line of input. This particular one-liner can be implemented reliably as follows: % ps | (read header; echo $header; grep sh) PID TT STAT TIME COMMAND 3415 0 Ss 0:00.31 -zsh (zsh) 3476 0 S+ 0:00.00 -zsh (zsh) because read is a shell built-in, and the shell guarantees that it will not consume more input than necessary. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: proposed change to style(9): require yoda style if statements
Dominic Fandrey writes: > Dag-Erling Smørgrav writes: > > Your .sig is strangely appropriate... > Not my invention, this is a pretty common one, used by many people > on the net. I actually have no idea where it comes from. My point is that it is strangely appropriate to the topic we are discussing. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: proposed change to style(9): require yoda style if statements
Dominic Fandrey writes: > I think the pro-yoda faction actually has more convincing arguments, Which ones? Never seen any beyond the basic "helps avoid accidentally typing = instead of ==". It's bollocks, anyway, because a) for every (variable == constant) comparison you have ten (variable == variable) comparisons and b) good compilers will warn about bare assignments used as conditions. The only practical effect of Yoda style is to make code harder to read. Your .sig is strangely appropriate... DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: /etc in CVS
Sergey Babkin writes: > I wonder if a version control system, like SVN, could be used to keep > track of all the changes in /etc. (Or maybe it already is and I'm > simply out of date). arch is commonly used for things like this. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: [RFC] The official logo for logo_saver?
Jung-uk Kim writes: > Although I really like logo_saver with Beastie, we have the official > FreeBSD logo and I think it is time to say good-bye to the old logo > image file. The attached file is a drop-in replacement for > sys/dev/syscons/logo/logo.c. > > What do you think? I agree, please commit. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Dynamic ticks in FreeBSD
Julian Elischer writes: > Who are you? and what have you done with DES? I gave him a week off... DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Newbie question: kernel image a dynamically linked binary?
Gary Jennejohn writes: > Daniel Rodrick writes: > > $ file kernel > > kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), > > dynamically linked (uses shared libs), not stripped > file is confused. FreeBSD uses a monolithic kernel and no shared > libraries are involved. However, it is possible to dynamically load > modules using kldload. See the appropriate man page. File is right. The kernel contains relocation entries so kernel modules can be linked against it. "monolithic" means something else entirely. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Dynamic ticks in FreeBSD
Tsuyoshi Ozawa writes: > Julian Elischer writes: > > Who are you? and what have you done with DES? > Sorry [...] Never mind, Julian was making a joke at my expense. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Newbie question: kernel image a dynamically linked binary?
Dag-Erling Smørgrav writes: > File is right. The kernel contains relocation entries so kernel modules > can be linked against it. "relocation entries" is possibly not the right term, someone with better knowledge of ELF will have to correct me. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: grep
Mark nesterovych writes: > Decided to write BSD licensed grep and provide it to FreeBSD project if > success. There is one already: textproc/bsdgrep. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Dynamic ticks in FreeBSD
Tsuyoshi Ozawa writes: > I started to work dynamic ticks in FreeBSD, and now experimental > code start to work roughly. This is great! I haven't looked at the patch, but I'm very happy that someone actually implemented this. We've been talking about it for years, and there was actually a GSoC project last year, but nothing came out of it. I really hope we can commit this soon! BTW, at one point, in your blog, you write "periodic tick mode" instead of "dynamic tick mode", which had me confused for a moment. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: periodically save current time to time-of-day hardware
Peter Jeremy writes: > Traditionally, the (PC) RTC is on the ISA bus (though it's possible it > might use I2C on other architectures or LPC on current PCs). AFAIK, it's usually on I2C on non-i386 platforms. I2C RTC chips are dirt cheap and easy to integrate, especially if you already have I2C temperature sensors and whatnot. > > Actually, it might be a good idea to call resettodr() any time the > > clock is stepped. > This should occur now via kern_time.c::settime(). OK. > Given that: > - resettodr() needs to be serialised; > - resettodr() may take a significant amount of time; and > - resettodr() should ideally be synchronised to the second boundary; > maybe creating a kthread to manage the RTC updating is reasonable. If "synchronised to the second boundary" means what I think it means (set the RTC at the exact top-of-the-second), don't go out of your way to implement that. You don't get that kind of accuracy back when you read it anyway - unless it's a calibrated RTC (I've written a Linux driver for one, hence my familiarity with eleven-minute-mode etc.) > A new kthread which sleeps on channel "update_rtc". When woken, it > checks to see if it's within (say) 50msec of a second boundary and so, > it does a trylock on the (new) RTC mutex. If it grabs the mutex then > it performs the update. If it was too far from the second boundary or > it fails to grab the mutex then it sleeps until the next second > boundary and tries again. > > The existing resettodr() would then turn into a wakeup(update_rtc). Sounds good to me, but if only that thread has access to the RTC, why bother with a mutex? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: periodically save current time to time-of-day hardware
Peter Jeremy writes: > It's not especially important how regularly the RTC is updated, just > that it _is_ updated. This suggests that an alternative approach > would be for adjtime() / ntp_adjtime() to directly call resettodr() if > it's more than P minutes since resettodr() was last called. It just occurred to me that resettodr() is very slow (it usually involves writing to NVRAM over an I2C bus), so it might not be a good idea to call it from adjtime(). > As a general comment, whilst resettodr() needs to be serialised, there > is no need for it to block. If thread B wants to call resettodr() > whilst thread A is doing so, thread B can just skip the call because > calling resettodr() twice in quick succession has no benefit. It does if thread B set the system clock before calling resettodr() (think ntpd -gq). Actually, it might be a good idea to call resettodr() any time the clock is stepped. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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"