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: Make ZFS use the physical sector size when computing initial ashift
Steven Hartland kill...@multiplay.co.uk 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
Re: considering i386 as a tier 1 architecture
Wojciech Puchar woj...@wojtek.tensor.gdynia.pl writes: Lev Serebryakov l...@freebsd.org 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 m.e.sanlit...@gmail.com 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
Mehmet Erol Sanliturk m.e.sanlit...@gmail.com 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: considering i386 as a tier 1 architecture
Mehmet Erol Sanliturk m.e.sanlit...@gmail.com 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
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: Turn on CLANG_IS_CC when not building gcc
Dimitry Andric d...@freebsd.org writes:
Dag-Erling Smørgrav d...@des.no 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
Re: FreeBSD needs Git to ensure repo integrity
grarpamp grarp...@gmail.com 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 kostik...@gmail.com writes: Dag-Erling Smørgrav d...@des.no 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
Re: fdgrowtable() cleanup
Konstantin Belousov kostik...@gmail.com writes: Dag-Erling Smørgrav d...@des.no 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
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 do...@freebsd.org 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
Avleen Vig avl...@gmail.com 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: Replacing BIND with unbound
Avleen Vig avl...@gmail.com 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
Gabor Kovesdan ga...@freebsd.org 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
Mark Blackman m...@exonetric.com 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
Mark Blackman m...@exonetric.com 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 m...@exonetric.com 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: Pull in upstream before 9.1 code freeze?
Robert Simmons rsimmo...@gmail.com 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: Pull in upstream before 9.1 code freeze?
Doug Barton do...@freebsd.org 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: Does anyone use nscd?
Lawrence Stewart lstew...@freebsd.org 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?
Daniel O'Connor docon...@gsoft.com.au 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?
Michael Bushkov bush...@freebsd.org 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
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: Does anyone use nscd?
Trond Endrestøl trond.endres...@fagskolen.gjovik.no 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
Re: Does anyone use nscd?
Artem Belevich a...@freebsd.org 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?
Samuel Martín Moro faus...@gmail.com 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: setting a random password with PAM API
Christopher J. Ruwe c...@cruwe.de 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 jakub_l...@mailplus.pl writes: http://marc.info/?l=openbsd-techm=129236621626462w=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 mark...@gmail.com 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 ba...@bitblocks.com 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: find(1): Is this a bug or not?
Bakul Shah ba...@bitblocks.com writes: Dag-Erling Smørgrav d...@des.no 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: Unhappy with cross-worlding
Julian Elischer jul...@freebsd.org writes: Garrett Cooper gcoo...@freebsd.org 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: 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: dump cache performance
Peter Jeremy peterjer...@acm.org 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: dump cache performance
Peter Jeremy peterjer...@acm.org writes: Dag-Erling Smørgrav d...@des.no 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: Summary: Re: Spin down HDD after disk sync or before power off
Alexander Best arun...@freebsd.org 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: Summary: Re: Spin down HDD after disk sync or before power off
Alexander Best arun...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no 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
Bruce Cran br...@cran.org.uk 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 arun...@freebsd.org 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
RW rwmailli...@googlemail.com writes: Alexander Best arun...@freebsd.org 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
Bruce Cran br...@cran.org.uk 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: Why is TUNABLE_INT discouraged?
Garrett Cooper gcoo...@freebsd.org 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 gcoo...@freebsd.org 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 arun...@freebsd.org 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 arun...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: Alexander Best arun...@freebsd.org 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: /stand/camcontrol
Xin LI delp...@gmail.com 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
Re: Support for WD Advanced Format disks
Andresen, Jason R. jandr...@mitre.org writes: Dag-Erling Smørgrav d...@des.no 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: expand_number() for fetch'es -B and -S switches
Alexander Best arun...@freebsd.org 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: /stand/camcontrol
Xin LI delp...@gmail.com writes: Dag-Erling Smørgrav d...@des.no writes: Xin LI delp...@gmail.com 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 arun...@freebsd.org 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: expand_number() for fetch'es -B and -S switches
Alexander Best arun...@freebsd.org 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 arun...@freebsd.org 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
/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: Support for WD Advanced Format disks
Ilya Bakulin webmas...@kibab.com 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 webmas...@kibab.com 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: Support for WD Advanced Format disks
Thiago Damas tda...@gmail.com 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: hexdump(1)/od(1) skip function off-by-one when offset == file length
Alexander Best arun...@freebsd.org writes: *hehehe* that might be true. maybe they've bought the src from ATT? 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
Ilya Bakulin webmas...@kibab.com writes: Dag-Erling Smørgrav d...@des.no 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: Winbond Watchdog
Daniel O'Connor docon...@gsoft.com.au 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: Why is TUNABLE_INT discouraged?
Garrett Cooper gcoo...@freebsd.org writes:
Dag-Erling Smørgrav d...@des.no 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
jhell jh...@dataix.net 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: Support for WD Advanced Format disks
Bakul Shah ba...@bitblocks.com 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
Matthew Jacob m...@feral.com 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
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: Support for WD Advanced Format disks
Bakul Shah ba...@bitblocks.com 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
Re: Why is TUNABLE_INT discouraged?
Ivan Voras ivo...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no 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 gcoo...@freebsd.org 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: glabel force sectorsize patch
Marius Nünnerich mar...@nuenneri.ch 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: glabel force sectorsize patch
Ivan Voras ivo...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: Marius Nünnerich mar...@nuenneri.ch 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: Winbond Watchdog
Xin LI delp...@delphij.net 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: Why is TUNABLE_INT discouraged?
Garrett Cooper gcoo...@freebsd.org 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: Why is TUNABLE_INT discouraged?
Ivan Voras ivo...@freebsd.org 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 gcoo...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no 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: Using lex in a shared library
Not related to your problem, but related to $SUBJECT: make sure to use -Psomething 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 delp...@delphij.net writes: Dag-Erling Smørgrav d...@des.no 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?
Matthew Jacob m...@feral.com writes: Xin LI delp...@delphij.net 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: Supermicro BIOS's watchdog feature?
Xin LI delp...@delphij.net 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: Help with some makefile hackery
Patrick Mahan ma...@mahan.org writes: In the top-level makefile I have the following label: src-kernel: src-kernel-tools cd src; ./amd64-kernel.sh 21 | 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: Help with some makefile hackery
Patrick Mahan ma...@mahan.org writes: Maybe I should do this instead? src-kernel: src-kernel-tools cd src; ./amd64-kernel.sh 21 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: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
Andriy Gapon a...@icyb.net.ua 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: using cupsd instead of base lpr
Ed Schouten e...@80386.nl 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: Help with some makefile hackery
Patrick Mahan ma...@mahan.org 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 machine-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 ba...@bitblocks.com 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 do...@freebsd.org writes: Bakul Shah ba...@bitblocks.com 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: head behaviour
Doug Barton do...@freebsd.org 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
prompt
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: proposed change to style(9): require yoda style if statements
Dominic Fandrey kamik...@bsdforen.de 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: proposed change to style(9): require yoda style if statements
Dominic Fandrey kamik...@bsdforen.de writes: Dag-Erling Smørgrav d...@des.no 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: /etc in CVS
Sergey Babkin bab...@verizon.net 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 j...@freebsd.org 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: Newbie question: kernel image a dynamically linked binary?
Dag-Erling Smørgrav d...@des.no 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: Dynamic ticks in FreeBSD
Tsuyoshi Ozawa ozawa+...@t-oza.net writes: Julian Elischer jul...@elischer.org 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?
Gary Jennejohn gary.jennej...@freenet.de writes: Daniel Rodrick daniel.rodr...@gmail.com 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
Julian Elischer jul...@elischer.org 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: Dynamic ticks in FreeBSD
Tsuyoshi Ozawa ozawa+...@t-oza.net 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: grep
Mark nesterovych m.nesterov...@gmail.com 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: periodically save current time to time-of-day hardware
Peter Jeremy peterjer...@acm.org 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: Another tool for updating /etc -- lua||other script language bikeshed
Ivan Voras ivo...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: Bourne shell is a perfectly fine programming language if you know how to use it. I'll agree that it's fine but only in the abstract - e.g. that it is Turing complete :) Emphasis on if you know how to use it. It's like Perl - it's easy to learn how to write bad Perl or Bourne shell code, but much harder to learn how to use them properly. 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
