Re: Lockdown adaX numbers to allow booting ?
In article <20190920155304.gn3...@zxy.spb.ru>, s...@zxy.spb.ru writes: >Location of device in multi-chassis storage system is different story. >I am don't know how to field engineer insert disks in chassis. >For me simple is find in /var/run/dmesg.boot S/N <=> daXY mapping and >turn ON led by sas2ircu. sesutil does this for you! # sesutil locate daXY on # sesutil locate daXY off So long as your enclosure supports SES (all the modern ones I've seen do) and is enumerable by ses(4). -GAWollman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: How to access SIGWINCH?
In article <20180513201344.ga34...@ptrace.hagen.corp> you write: >I'm wondering how to get access to to the SIGWINCH signal. It is defined in >/usr/include/sys/signal.h and behind the -D__BSD_VISIBLE switch. > >I can compile my code with this switch, but is this the proper way to do it? >I would expect something like this behind -D_BSD_SOURCE or >-D_XOPEN_SOURCE=700. > >What's the right way to access this signal? The right way is to *not* request strict adherence to a standard that doesn't include that signal. Do not define any of these macros and you will get SIGWINCH defined. The next POSIX revision will probably include SIGWINCH, so come 2022 you can define _POSIX_C_SOURCE to something like 202207 and get it. (I'm not actually certain when the next revision is planned to be released -- we just went through an IEEE-mandated reaffirmation cycle but I don't believe a new signal and the related data structures can be introduced in a technical corrigendum so it will have to wait for the next opportunity to do a full revision of standard, which will have to be agreed upon by IEEE, ISO/IEC JTC1, and The Open Group.) -GAWollman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: posix_fallocate on ZFS
In article , asom...@freebsd.org writes: >On Sat, Feb 10, 2018 at 10:28 AM, Willem Jan Withagen >wrote: >> Is there any expectation that this is going to fixed in any near future? >No. It's fundamentally impossible to support posix_fallocate on a COW >filesystem like ZFS. Ceph should be taught to ignore an EINVAL result, >since the system call is merely advisory. I don't think it's true that this is _fundamentally_ impossible. What the standard requires would in essence be a per-object refreservation. ZFS supports refreservation, obviously, but not on a per-object basis. Furthermore, there are mechanisms to preallocate blocks for things like dumps. So it *could* be done (as in, the concept is there), but it may not be practical. (And ultimately, there are ways in which the administrator might manage the system that would defeat the desired effect, but that's out of the standard's scope.) Given the semantic mismatch, though, I suspect it's unreasonable to expect anyone to prioritize implementation of such a feature. -GAWollman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem with ls, not show a correct list
In article <3a8b8ade882d1486aa41b448a9c83...@i805.com.br> you write: > > > It's a terrible Is it a locale bug? Look! > >% locale >LANG=pt_BR.UTF-8 >% touch E >% ls -l [a-z]* >-rw-r--r-- 1 rizzo wheel 0 7 abr 02:06 E No, it's the specification of how character ranges in glob(3) and fnmatch(3) work. In effect, character ranges like [a-z] must be treated as ranges of *collating elements*, not byte ranges, and in your locale, and are considered to be the same collating element, so [a-z] matches both upper- and lower-case Latin letters. This is documented, very obliquely, in sh(1), which also tells you the workaround: a character class. A character class matches any of the characters between the square brackets. A locale-dependent range of characters may be specified using a minus sign. A named class of characters (see wctype(3)) may be specified by surrounding the name with `[:' and `:]'. For example, `[[:alpha:]]' is a shell pattern that matches a single let- ter. So, to match only lower-case letters regardless of your current locale setting, you must use the correct character class: $ locale LANG=pt_BR.UTF-8 LC_CTYPE="pt_BR.UTF-8" LC_COLLATE="pt_BR.UTF-8" LC_TIME="pt_BR.UTF-8" LC_NUMERIC="pt_BR.UTF-8" LC_MONETARY="pt_BR.UTF-8" LC_MESSAGES="pt_BR.UTF-8" LC_ALL= $ ls D E F a b c $ ls [[:lower:]]* a b c The same applies to character class ranges in regular expressions, not just glob(3) patterns. -GAWollman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Heimdal in base
< said: > Well, it's definitely too late for 11, now. > But, Debian is preparing to remove their heimdal package entirely, > imminently: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837728 The primary issue, so far as I can see, is that Heimdal and MIT were only compatible in the parts of the API that were formally standardized. For those of us who need MIT (to have a working kadmin, for example), that has pretty much always boiled down to completely disabling Heimdal in base (and anything that depends on it, like OpenSSH, pam_krb5, and GSSAPI-authenticated NFS), and installing replacement bits from ports/packages. If we're going to remove Heimdal from base, we should completely deorbit (or disable, as appropriate) all of the things that depend on it, and make sure that there are ports that provide replacement functionality. (AFAIK the only thing missing is gssd, the user-mode side of the authenticated NFS support.) My bet would be that very few FreeBSD users actually take advantage of this support, and unless they're running in an all-FreeBSD or all-Heimdal shop probably have to install MIT Kerberos anyway. Since we're expecting to have packaged base complete for 12.0, having to install a few extra packages (and replace some base packages with ports packages) should not be an imposition, for those people who want Kerberos support, and for many of us it would make fresh installs less of a hassle. Since 11.0 hasn't been released yet, is it within the realm of possibility to officially deprecate Heimdal-in-base before it ships? At this stage all that would involve is putting an announcement in the release notes. -GAWollman (writing as the administrator of the CSAIL.MIT.EDU realm, but still not speaking for MIT) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: posix_fallocate(2) && posix_fadvise(2) are somewhat broken
In article sobo...@freebsd.org writes: >Hi, while working on some unrelated feature I've noticed that at least >those two system calls are not returning proper value (-1) on error. >Instead actual errno value is returned from the syscall verbatim, That is what the specification requires. RETURN VALUE Upon successful completion, posix_fadvise( ) shall return zero; otherwise, an error number shall be returned to indicate the error. (Quote from SUSv7 p. 1410, lines 46221-46223.) -GAWollman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
In article , oliver.pin...@hardenedbsd.org writes: >Btw, I have found this is atf's documantation: >atf_tc_expect_signal(SIGSEGV, "reaseon"), with this, we could mark the >specific test case could "fail" / or expect to coredump. No. I'm not sure why people are having trouble understanding this. The test in question is not valid C. It is entirely erroneous, and should be deleted. Merely computing the value "(void *)-1" is allowed to perform LITERALLY ANY ACTION AT ALL, including turning your computer into a frog. The compiler is free to implement this as a call to abort() if it chooses. Testing this is nonsensical. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
In article <559d8e55.9050...@freebsd.org> a...@freebsd.org writes: >I am not suggesting this but if our man pages used all capitals to signify >important auxiliary verbs then the ERRORS sections would read as > The following error codes MAY be set in errno: >Perhaps in that case it would be more clear how 'MAY' differs from 'SHOULD' and >'MUST'. >Of course, the manual pages seem to be too sloppy in this respect. No, it's just the standard meaning of "may" as defined in the POSIX standard. ISO standards in general use "shall" for mandatory behavior and "may" for optional behavior. (For every occurrence of the word "shall" in the POSIX standard, there should be a conformance test[1]; "may" covers behavior where implementations are allowed to differ with no conformance distinction being made.) In the specific case of library interfaces, "may fail and set the following code in errno" is slightly more restrictive: the implementation is required to raise that error if the associated condition is detected, but it is not required to detect that condition even if it is present, and it may indicate some other error condition that is present and detectable. -GAWollman [1] Technically, this applies only to "shall" where the subject is the implementation. POSIX also includes "shall" requirements on applications, which obviously can't be tested. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT
In article
oliver.pin...@hardenedbsd.org writes:
>We discovered that one of the kyua test failing from gettimeofday tests.
>The error is reproducible on recent snapshot from 11-CURRENT:
>ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/11.0/FreeBSD-11.0-CURRENT-amd64-20150630-r284969-disc1.iso
>
>root@freebsd:~ # cat test-gtod.c
>#include
>#include
>
>int
>main(int argc, char **argv)
>{
>
>return (gettimeofday((void *)-1, NULL));
>}
Undefined behavior here, so the implementation is allowed to do
literally anything at all. Certainly there's nothing wrong with it
dumping core here, and the test is erroneous if it expects otherwise.
The first argument to gettimeofday() MUST be a valid pointer to struct
timeval, and the implementation does depend on this.
Perhaps the test was (erroneously) written to assume that
gettimeofday() was a system call, and could therefore detect invalid
pointers and return [EFAULT]. This has not been the case for some
time. (In HEAD, not since r237434, which is three years ago.)
-GAWollman
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFS installworld failures
In article <54320e76.3010...@pinyon.org>, rcar...@pinyon.org writes: >Am I the only one attempting to maintain a local cluster using >a buildworld server and mounting /usr/src/ and /usr/obj/ via NFS? Nope. >I intermittently run into installworld failures, usually >in sys/boot/i386 but occasionally e.g. cddl/lib where the >install targets are apparently out of date, and want to be >rebuilt, which doesn't work with a read-only mount. I've seen errors like this on 9.3, and was somewhat concerned about 9.3's NFS implementation as a result. Never on 9.1 or 9.2. (Sorry, I don't have any 10.0 systems yet -- we'll go to 10.1 after Christmas.) I am wondering if it's at all related to my issue with bonnie++ failing when run over NFS on a 9.3 client. (I haven't tracked this down yet.) >Is this a reasonable thing to expect to work, or maybe not? It's supposed to work. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
In article you write: >Writing "an article" is hard. Writing a small section on how deleting >packages is different between pkg and, say, apt, is much easier. The >scope is known. Indeed, it's pretty trivial. I think the sort of article Craig was looking for was more on the order of apt command pkg command apt-get update pkg update (*1) ... ... (*1) Explanation of differences between how apt behaves and how pkg behaves. The set of common apt operations is pretty well-known, and most of them have direct pkg(8) equivalents. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: login.conf --> UTF-8
In article <1396457629.2280.2.ca...@powernoodle.corp.yahoo.com>, sbr...@freebsd.org writes: >I'd like to make this change to login.conf for default installs. > >This removes some amount of hackery in the ports system that is working >around our lack of UTF-8 in the base. I'm not sure what the connection is here. Surely the ports system runs with the locale of the user running "make" (which in my case is going to be "C"). Any port that requires a specific locale to build properly needs to be setting that locale explicitly. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Leaving the Desktop Market
In article <533b3903.7030...@rancid.berkeley.edu>, mich...@rancid.berkeley.edu writes: >I have been using FreeBSD on the desktop since 1997, Hmmm. I'm a bit biased here, but I've been using FreeBSD on the desktop since, well, before it was called FreeBSD. It's still my primary platform for nearly everything (except photo management, which drove me to a Mac laptop so I could run Lightroom, and those few remaining Web sites that still bury all their content inside Flash). But let's be clear that different people have different requirements for a "desktop". My requirements are relatively simple: twm, xterm, XEmacs, vlc, LaTeX, xpdf, a Jabber client (psi), $VCS_OF_CHOICE, gnucash, and at least two Web browsers (I use Opera for most stuff and Firefox for "promiscuous-mode browsing"). Once in a while, I even need to run a remote X application over an SSH tunnel. A Web server (Apache) and a mail server with local delivery and spam filtering (sendmail+spamass-milter+crm114) round out the requirements. I do not ever need or even want translucent windows, Zeroconf, 3-D games, or nonlinear video editing. Audio playback only matters to the extent that it's smooth and the settings stick. I write documents and code; my desktop is a productivity tool, not a gaming platform, and it performs that function quite well, thank you very much. Other people have rather different requirements, and that's OK. But let's please not break the applications for which FreeBSD is very good now (and has actually gotten substantially better). -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: firebox build fails post clang-3.4 merge
In article <530ea5cd.2070...@protected-networks.net>,
i...@protected-networks.net writes:
> .. way back in the late 70's or maybe early 80's when I was
>actually doing some work on compilers, we had a saying: "produce correct
>code even if it's not optimal or exit and tell the user why".
>
>Producing non-working code for no apparent reason and without warning is
>counter-productive. It wastes everyone's time :-(
When the specification of "correct" says that anything can happen,
including but not limited to the program crashing at runtime, there's
no limit on what the compiler may emit. (On the other hand, I agree
that if the compiler emits a "crashme" instruction, it really ought to
generate a diagnostic as well, even if it can't explain why.)
Originially this "escape hatch" was intended to apply to conditions
that the compiler could not detect (or at least, the historical PCC
could not detect), but nowadays the compiler writers take it upon
themselves to deliberately break programs that involve undefined
behavior, even when there is an entirely sensible way to define the
behavior which is consonant with the way the machine architecture
works and how historical compilers have implemented the same
construct. For example, the following program:
#include
extern long l;
int
main(void) {
l = LONG_MAX;
l++;
return l > 0;
}
..is permitted to crash, but it's also permitted to do nothing, and
it's permitted to set l to LONG_MIN (following the normal
two's-complement arithmetic on signed values). The compilers I
checked actually did the obvious thing, but they are older versions.
-GAWollman
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PACKAGESITE spam
In article <20131221230448.ga61...@troutmask.apl.washington.edu>, Steve Kargl writes: >Other than the noise in /var/log/message, what does this provide >that 'pkg info' doesn't! A record of when packages were installed and removed. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS: Invalid SEND/RECV stream still
In article , Larry Rosenman wrote: >Error Message: >received 320KB stream in 1 seconds (320KB/sec) >receiving incremental stream of vault/var@2013-10-25 into >zroot/backups/TBH/var@2013-10-25 >cannot receive incremental stream: invalid backup stream I've seen this happen in one very specific case: if the receiving machine is doing automatic snapshots, and happens to do a snapshot of the filesystem being received *while it's being received*. In that case, it appears that the filesystem on disk gets subtly corrupted, and the only remedy is to destroy it on the receiving machine and start all over (making sure to disable automatic snapshots this time). "zfs receive -F" will rollback snapshots made on the receiving system that don't exist on the sending system, but it only does this at the beginning of the stream -- it can't prevent further snapshots from being taken during reception of an incremental stream which foul up the works. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ports with daemons on uninstall...
In article <20130714191725.ga30...@stack.nl>, jil...@stack.nl writes: >Apart from the annoyance of the restarts, automatic stopping and >starting is probably the best policy for having things "just work". Some >daemons will crash or otherwise stop being useful when their files have >been deleted or replaced, and the new rc.d script might be unable to >stop the old daemon. Strongly agreed -- and it's what other operating systems do, either by policy or by convention. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADSUP] No more pkg_install on HEAD by default
In article <20130714064601$3...@grapevine.csail.mit.edu>, dte...@freebsd.org writes: >> [I wrote:] >> It accesses the sqlite database in /var/db/pkg that was previously >> retrieved from the remote repository. >Now from what you explained of pkg, I'm worried that for bsdconfig: > >1. Browse packages (nothing else) >2. Exit bsdconfig > >and now because the "pkg rquery" has staged a db, future "pkg" commands >are now influenced. Only if you update /usr/local/etc/pkg.conf to set a permanent PACKAGESITE. Otherwise, it will notice that the remote repo catalog you have isn't for your currently selected remote repo, and use that instead. >> You really shouldn't know about the actual format of the tarballs; >> your time would be better spent learning the new "pkg create", "pkg >> register", and "pkg repo" commands. Depending on your needs, you >> might want to write to the libpkg API instead. >That won't work for us. > >You're not going to like the answer, but it does mean that things like >"pkg create", "pkg register" and "pkg repo" won't work for us. Congratulations for building your entire workflow around a horrible kluge straight out of 1993. FreeBSD, however, is moving on. (And it's long past time!) Your developers will just have to deal. Or you can maintain the old cruft for your business -- just don't expect anyone else to use it, or even want to. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADSUP] No more pkg_install on HEAD by default
In article <20130714054840$7...@grapevine.csail.mit.edu>, dte...@freebsd.org writes: >How about rquery? What protocol does that use? and what does it talk to? It accesses the sqlite database in /var/db/pkg that was previously retrieved from the remote repository. >Question: Where can I learn more about the actual format of what's in >the new tarballs? This is going to be important not for bsdconfig, but >$work (we have our own build platform; I'm going to have to rewrite it >from mastering PLIST files to mastering YAML MANIFEST files and I want >to know all the gritty details). You really shouldn't know about the actual format of the tarballs; your time would be better spent learning the new "pkg create", "pkg register", and "pkg repo" commands. Depending on your needs, you might want to write to the libpkg API instead. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
< said: > I think isnan(double) and isinf(double) in math.h should only be > visible if (_BSD_VISIBLE || _XSI_VISIBLE) && __ISO_C_VISIBLE < 1999. > For C99 and higher there should only be the isnan/isinf macros. I believe you are correct. POSIX.1-2008 (which is aligned with C99) consistently calls isnan() a "macro", and gives a pseudo-prototype of int isnan(real-floating x); -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule
In article <20120712100110.ga34...@ithaqua.etoilebsd.net>, b...@freebsd.org writes: > - puppet support: (https://github.com/xaque208/puppet-pkgng) I've actually already written one of these; it may be good to merge. Would whoever is working on this please raise your hand? -GAWollman -- Garrett A. Wollman| What intellectual phenomenon can be older, or more oft woll...@bimajority.org| repeated, than the story of a large research program Opinions not shared by| that impaled itself upon a false central assumption my employers. | accepted by all practitioners? - S.J. Gould, 1993 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mbstowcs(3) may not return -1
In article <4fe340ff.80...@gmail.com>, demelier.da...@gmail.com writes: >On 21/06/2012 14:55, Sergey Kandaurov wrote: >> It returns (size_t)(-1). >> I don't know how is it correct, but this conforms to C spec. >Mm, if I understand well, since it is cast to size_t, I think the return >value will be SIZE_MAX - 1 then, right? No. C does not make any such equivalence. "(size_t)-1" is the one correct spelling of this value (modulo redundant additional parentheses), and that's how the standard writes it. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New installation script
In article <4e3d55fd.7090...@freebsd.org>, nwhiteh...@freebsd.org writes: >I'm not entirely sure what you're referring to. Whenever you add a / >partition on a partitioning scheme that requires a boot partition (APM, >GPT on some platforms), the installer asks you if you want to add a boot >partition. The auto-partitioner does this automatically. It does not >reuse any existing boot partition for two reasons: >- It has no way to know the other boot partition was correctly set up >and so would need to reinitialize it. >- There is no guarantee that it is even related to FreeBSD. On APM >disks, we share a boot partition type with OS X and Linux. Having just been through this, I can only say that neither of these arguments apply when the boot partition exists only in the memory of the partition editor and was never on the (freshly initialized) disk. I was a bit taken aback when I deleted and recreated the / partition (since I didn't want the "everything in one partition" layout it defaulted to) and it wanted to create *another* boot partition. Another issue I had was that it was unclear which keymap I was expected to choose. I initially chose "traditional Unix workstation", which was unusable. (Never did find the control or escape key, which made vi particularly difficult to use.) The default selection in the keymap dialog ought to be "don't screw with it" rather than an option which is not obviously correct. Forcing users to set a system timezone is probably a good idea, too; I had not noticed that it never asked me for one until I ran the "date" command and found my system running in UTC. The new version of dialog feels cheesy compared to the old one. (Unrelated to the installer:) There's a lock order reversal the first time a new directory is created, and another one when the system is rebooted. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Difficulty playing DVDs under AHCI/CAM?
< said: > Not sure if debugging with CAMDEBUG would be easier or not. > There could be lots of output. I never found out, as once I rebooted with the new CAMDEBUG-ified kernel, everything started working. No idea why. (Maybe the DVD player just wanted to be rebooted with a disc in it?) -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Difficulty playing DVDs under AHCI/CAM?
< said: > Just want to draw attention of those who use ahci, have hald running and burn > optical media to couple of known issues: What about those of us who use ahci, don't have hald running, and just want to read their DVDs? I never heard any response from you when I asked for a more specific debugging procedure. My next step was going to be enabling CAMDEBUG and trying to find out which specific operation was failing, but I'm not a SCSI expert by any means -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Difficulty playing DVDs under AHCI/CAM?
In article <4c79499b.3050...@icyb.net.ua> a...@icyb.net.ua writes: >> [I wrote:] >> ...say what? Why is the cd driver suddenly returning ENXIO? > >Strange indeed. >Can you dtrace this read? You can use combination of syscall and fbt providers >with execname predicate. You're going to have to be much much more specific than that. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Difficulty playing DVDs under AHCI/CAM?
After a recent upgrade, I switched to AHCI/CAM for my SATA devices,
including a new DVD drive. Now I find that nothing can play DVDs any
more. For example, here's what mplayer does:
8469 initial thread CALL open(0x806c25450,O_RDONLY,0)
8469 initial thread NAMI "/dev/cd0"
8469 initial thread RET open 3
8469 initial thread CALL fstat(0x3,0x7fffb410)
8469 initial thread STRU struct stat {dev=50396928, ino=89, mode=crw-r-
, nlink=1, uid=0, gid=5, rdev=89, atime=1282953341.461532000,
stime=1282953341.461532000, ctime=1282953341.461532000, birthtime=-1, size=0,
blksize=4096, blocks=0, flags=0x0 }
8469 initial thread RET fstat 0
8469 initial thread CALL ioctl(0x3,DVDIOCREADSTRUCTURE,0x7fffac30)
8469 initial thread RET ioctl 0
8469 initial thread CALL ioctl(0x3,DVDIOCREPORTKEY,0x7fffb430)
8469 initial thread RET ioctl 0
...so two DVD-specific ioctl calls succeed...
8469 initial thread CALL
open(0x7fffbcd0,O_RDWR|O_CREAT,S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH)
8469 initial thread NAMI "/home/wollman/.dvdcss/CACHEDIR.TAG"
8469 initial thread RET open 4
...write to this file omitted for clarity...
8469 initial thread CALL close(0x4)
8469 initial thread RET close 0
8469 initial thread CALL read(0x3,0x7fffb4d0,0x800)
8469 initial thread RET read -1 errno 6 Device not configured
...say what? Why is the cd driver suddenly returning ENXIO?
8469 initial thread CALL lseek(0x3,0,SEEK_SET)
8469 initial thread RET lseek 0
8469 initial thread CALL lseek(0x3,0x8,SEEK_SET)
8469 initial thread RET lseek 524288/0x8
8469 initial thread CALL read(0x3,0x7fff6000,0x800)
8469 initial thread RET read -1 errno 6 Device not configured
8469 initial thread CALL write(0x2,0x7fffb2b0,0x43)
8469 initial thread GIO fd 2 wrote 67 bytes
"libdvdnav:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.IFO failed
"
Same results (but without error messages) in vlc. My drive is
identified as:
at scbus0 target 0 lun 0 (pass0,cd0)
-GAWollman
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why GNU grep is fast
In article <20100822163644.gu2...@hoeg.nl> you write:
>I think that implementing a simple fgrep boils down to mmap()ing a file
>and calling memmem() on the mapping to search for the input string. Of
>course this relies on having an efficient memmem() implementation, for
>example using one of the algorithms mentioned in this thread.
It's actually more complicated than that, because you have to ensure
that you are not matching the middle of a multibyte character, when
the current locale specifies a character set with a multibyte
encoding. Likewise when searching for the newlines that delimit the
matched line. (I'm not sure whether FreeBSD supports any character
encodings that would be ambiguous in that way.) I don't think this
was considered an issue when Mike Haertel was developing GNU grep.
It seems reasonable to implement BMG or some other fast search in
memmem(). Note that if you can't (or don't want to) mmap the whole
file at once, you'll need special handling for the boundary conditions
-- both at the string search level and at the search for line
delimiters. This is much easier in the fgrep case, obviously, since
the length of the query puts a finite upper bound on the amount of the
old buffer you need to keep -- with regexps you really need your
regexp engine to be able to report its matching state, or else limit
your input to strictly conforming POSIX text files (i.e., line lengths
limited to {LINE_MAX}).
-GAWollman
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why GNU grep is fast
In article <86k4nikglg@ds4.des.no> you write: >Mike Haertel writes: >> GNU grep uses the well-known Boyer-Moore algorithm, which looks >> first for the final letter of the target string, and uses a lookup >> table to tell it how far ahead it can skip in the input whenever >> it finds a non-matching character. > >Boyer-Moore is for fixed search strings. I don't see how that >optimization can work with a regexp search unless the regexp is so >simple that you break it down into a small number of cases with known >length and final character. The common case of regexps used in the "grep" utility (and, for obvious reasons, universal in the "fgrep" utility) is fixed-length search strings. Even non-fixed-length regexps typically consist of one one or two variable-length parts. Matching a completely variable-length regexp is just hard, computationally, so it's OK for it to be slower. There are other tricks you can do, such as turning the anchors ^ and $ into explicit newlines in your search -- "^foo" is a very common regexp to search for, and it's really a fixed-string search for "\nfoo" which is entirely amenable to the B-M treatment. You just have to remember that a matched newline isn't part of the result. The GNU regexp library also uses the Boyer-Moore (or is it Boyer-Moore-Gosper?) strategy. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] BSDL iconv in base system
In article <86bpba7nc1@ds4.des.no>, d...@des.no writes: >This means you can't, say, read data from a file into a buffer and then >pass that buffer to iconv, because the buffer is not const (otherwise >you couldn't have read data into it). That seems like a pretty >fundamental flaw. But it's a fundamental flaw in the specification of C that "pointer to pointer to X" and "pointer to pointer to const X" are incompatible in this particular way (which is not required by any machine for which there exist C99 compilers). In general, the addition of "const" to C in 1989 was a bit of a botch: it isn't as strong as people expect it to be, and there are these weird corners. (Another thing the committee left out was any way to declare a "conforming" function, in which the return type has the same qualifiers as one of its arguments -- see strchr() for example.) That's water under the bridge now, of course. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Our aging base system heimdal
< said: > Is anybody planning to update the base system heimdal, which has been > largely untouched since May 2008? I would love for it to go away entirely, and those base-system components that depend on it to learn how to use either Kerberos implementation from ports. (I'd also love for the ancient and broken base version of libcom_err to go away -- there's no knob to turn it off, and the shared library conflicts with ports/krb5.) (And yes, this is a bit of an irony considering that I used to be the maintainer of the base-system Kerberos code in the long-ago krb4 days. But my job requires me to administer MIT Kerberos, so I need the MIT kadmin utility and not the Heimdal one.) -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: propose: all arch move into a separate dir
In article <20100307.144736.420173476735197890@bsdimp.com>, Warner Losh writes: >We don't have quite as many problems as the NetBSD/OpenBSD crowd in >this respect. They tend to define a new MACHIINE more often then we >have (or will). The need for sys/arch is less severe here than there >because we don't have 40 different MACHINEs. Even if we did, I cannot think of any compelling reason to make such a change (and I don't recall one ever being brought up in our entire history). If we had forty architecture directories in /sys, so what? Why should it matter to anyone? If we were talking about 100 architectures, I might feel differently, but in this universe, we have, what? eight? And there are how many architectures currently in mass production? This whole discussion is ridiculous. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NSS and PAM
< The problem is that the authentication information needs to be stored > somewhere, and the usual solution is to store it in the directory, ...which is usually the worst possible place. Please don't penalize those of us with sensible authentication systems. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: /bin and /sbin are now dynamically linked
< said: > We have made the assumption for the first three options since day one. > Why should we change the assumptions just because we now have a dynamic > /? Because we are not all masochists. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
< said: > There have been a lot of proposed solutions: > * Rewrite NSS to not require dlopen(). > * Rewrite dlopen() to not require dynamic linking. > * Don't support NSS in /bin/sh. > * Change the default script interpreter for rc and such. > * Make dynamic linking faster. You forgot: * Allow statically-linked programs to use dynamic NSS modules by forking a (dynamically-linked) resolver process when needed. This leads to a related, but widely disparaged option: * Have a persistent NSS caching daemon with an RPC interface that all programs can access for NSS lookups. You might call such a program `nscd'. (Might as well be honest about it.) Both of these options may incidentally help to resolve threading issues in the C library (although that would not be the preferred way of doing so). -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
< said: > well, try to think about non-minimalism when you're trying to track > down a kernel bug in a zillion SLOC ... How about trying to think about FreeBSD when posting on the FreeBSD mailing-lists. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone object to the following change in libc?
< said:
> POSIX requires in addition [u]int{8,16,32}_t, and [u]int64_t if 64 bit
> integer types exist. It says that the existence of int8_t implies
> that a byte is 8 bits and CHAR_BIT is 8. I'm not sure what prevents
> int8_t being smaller than char.
Nothing can be smaller than char (except bitfields, which you can't
take the size of anyway).
The full story:
The POSIX sockets standard (I forget which letter it had) introduced
uint8_t et al, but was aligned to C90. That amendment was integrated
into the main text at the same time as C99 was, and late in the
process we realized that C99's definition of uint8_t is much stricter
than what the socket standard expected. (Specifically, the socket
standard allows uint8_t to have padding bits that do not participate
in the domain of the type, but C99 does not.) Faced with the choice
of having to invent from whole cloth a completely new set of
interfaces to describe packing and unpacking eight-bit network data in
nine- or sixteen-bit characters, or specifying an explicit byte size,
we chose the latter. It helped that there were no more 36-bit
platforms to be concerned about. (Some would say that this was a
rather belated recognition of a choice the industry made two decades
ago There was, however, a 36-bit implementation of FIPS 151-2, by
UNISYS.)
-GAWollman
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Software RAID
< said: > So there is no way to mirror the root so if one drive fails, > i can't have the other drive boot up ? There are ways to do that, but in order for that to work at all you need to have BIOS support. Some of the ATA ``RAID'' products work like that: they have BIOS support for mirroring/failover, but the operating system has to do all the work once it's booted. FreeBSD supports these controllers reasonably well, and they are quite economical. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jumbograms (& em) & nfs a no go
< said: > Just a minor note: GigE should not require a crossover cable. It's > supposed to work to connect two GigE adapters with a straight-thru > cable. I verified this with two Intel em NICs, quite a while ago. This should hardly be surprising, since 1000BASE-TX transmits and receives bidirectionally on all four pairs simultaneously. > As I recall, when I used a crossover cable, I could not get the > adapters to go to 1000, only 100. That might have been the cable, > or not. That's at least conceivable; I don't know enough about the wire protocol to tell whether that's supposed to happen or not. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone object to the following change in libc?
< said: > "The c89 utility (which specified a compiler for the C Language specified > by the 108 ISO/IEC 9899: 1990 standard) has been replaced by a c99 utility > (which specifies a compiler for 109 the C Language specified by the > ISO/IEC 9899: 1999 standard)." More specifically: IEEE Std. 1003.1-2001 is aligned to ISO/IEC 9899:1999 in all respects. C99 alignment was one of the principal reasons for bringing out a whole new standard in the first place, rather than continuing the amendment process. (This is also why POSIX now requires eight-bit bytes.) -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sysinstall's fdisk/disklabel should be improved
< said: > initial complaints, I do think that fdisk/disklabel in sysinstall > need to be improved upon. They do not handle multi-terabyte disk > arrays properly at all You should probably use GPT on multi-terabyte disk arrays. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
getdirtybuf: interlock not locked but should be
I'm working on getting the AFS client to work under FreeBSD. I just compiled a -current kernel with DEBUG_VFS_LOCKS, and before I could even load the AFS module I had the system stop with the following locking assertion: getdirtybuf: 0xc2678000 interlock is not locked but should be Backtrace looks like: getdirtybuf(de17cbb4, 0, 1, c7732ba0, 1) +0xee flush_deplist(c268ad4c, 1, de17cbdc, de17cbe0, 0) +0x43 flush_inodedep_deps(c267,1ab,,c26ed000,124) +0xa3 softdep_sync_metadata(de17cca4, 0, c037b672, 124, 0) +0x87 ffs_fsync(de17cca4, c03714ea, c0373416, ad8, 0) +0x3b9 fsync(c25d7850, de17cd10, c038276b, 3ec, 1) +0x1d4 syscall() ... One vnode is locked: 0xc26ed000: tag ufs, type VREG, usecount 1, writecount 1, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc25d7850 ino 427, on dev ad0s1a (4, 13) This is repeated four times with the same vnode. Obviously, it would help to have a solution to this problem so that I can debug what I'm really interested in rather than worrying about UFS. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Fixing -pthreads (Re: ports and -current)
< said: > think '-pthread' is a good thing. It's nice to have a portable way to say > that I want to compile POSIX code. What good is a standard if there's no > standard way to get to it? The Standard way to do it is: c99 foo.c -l pthread -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
< said: > Eek, no. Libpthread is libpthread, libthr is libthr, etc. A > symlink doesn't help you anyways because the library/application > becomes dependent on the thing it is symlink'd to, not the > symlink. That depends on what the SONAME entry says It is technically feasible to have libpthread.so by a symlink, provided that all three thread libraries cooperate by announcing an SONAME of libpthread.so.N. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Fixing -pthreads (Re: ports and -current)
I think it was John Baldwin who wrote: >> I think having a magic option to gcc that translates to 'link with the >> foo library' is rediculous. What's next, a gcc -math to get the math >> functions in libm? As far as POSIX is concerned, that's precisely how it works. `c99 foo.c -l m' means `link in the math functions, wherever they may happen to live'. Likewise `-l rt' for realtime -- and (relevant to this discussion) `-l pthread' for threads. There is no requirement that any of these libraries exist as such. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)
< said: > In theory, yes. In practice, maybe not. If I remember correctly, > the problem we're trying to solve is twofold: Actually, the problem we were trying to solve is simpler than that. genassym needs to be able to compute the values of certain constants from header files which are only accessible to kernel code. At the same time, it needs to be able to run as a user process. One compilation unit cannot include both Standard headers like and kernel-specific headers like . In fact, we muck with the include path to ensure that Standard headers cannot be included while compiling kernel source. Cross-compilation does engender other issues, but that wasn't the original motivation. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Someone help me understand this...?
< said: > The only way to close this sort of race is to have a notion of a > unique process identifier that lasts beyond the lifetime of the > process itself -- i.e., the ability to return EMYSINCERESTREGRESTS > if you try to signal a process after it has died, and have a > guarantee that the handle won't be reused. This is traditionally done by holding an advisory lock on the pid file; if the file is no longer locked, then the process holding the lock must have exited. You could also do it with UUIDs and a more heavyweight signal API. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HTT on current
< said: > There are two problems with HTT. First, L1/L2 cache issues. Second, the > virtual CPUs are not independent, and there are many cases where > instructions in one virtual CPU stall the other. So take, for example, > the case of a userland application on CPU0 stalling the kernel on CPU1. I don't think that this is quite stated right. The problem is that the P4 is not very wide to begin with, and it's very hard to optimize well for that 23-stage pipeline.[1] So if you have a thread with lots of latent ILP (either because you did a good job optimizing it for a four-way superscalar, or because you did a bad job scheduling it and are depending on the processor to make up for the naive optimization), it is bound to run more slowly when some of the functional units it could have used are taken by another thread of execution. But some sorts of applications can benefit, if the application can be decomposed into threads that exercise different FUs (for example, one thread that is memory intensive and one thread that is compute intensive). The challenge then is to make sure that they always get scheduled on the same processor at the same time. The key to getting good performace on an SMT architecture with an arbitrary instruction mix is more functional units. The never-built Alpha EV8, which was to be an eight-way superscalar with four-way SMT and a wide memory bus, would be much easier with which to achieve optimum performance. -GAWollman [1] That's why the Athlon gets more instructions per cycle: it has a much shallower pipeline and more functional units, so it can execute naively-optimized, ILP-heavy code much faster without stalling. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 64 bit quantities in statfs ?
< said: > Yep, looks broken. In the POSIX standard, the functionality of > statfs() is provided by statvfs(), so implementing the latter may > be a way out that doesn't involve breaking any ABIs. statfs() is a lot more useful interface than statvfs(). I'd like to keep statvfs() as the ``standard'' interface, rather than extending it to cover all of the information that statfs() has. In order to grow statfs() we need to rev libc. It might be appropriate to do that in the 5.2 time frame, if we are still anticipating that 5.2 will be the -stable crossover point. RE team? -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SAN disk with freebsd?
< said: > Anyone using a storage area network with freebsd (or linux)? Anything to > recommend as working well or to stay way from? We have two SANs with FreeBSD and Debian servers on them, sharing (and booting from) a generic RAID array (Mylex controller IIRC). The HBA is a Qlogic QLA-2200. Things to stay away from: - Pure FC-AL topologies - Windows on the same loop as anything else - Storage devices that can only be managed through a proprietary Windows application -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SAN disk with freebsd?
< said: >> - Windows on the same loop as anything else > Liberal use of zoning should help that. Each Windows HBA should be in a > seperate zone. This is from personal experience and also assumes you are > using a switched fabric. I said ``loop'' for a reason. The configuration that we were sold is pure FC-AL. No fabrics. Don't do that, it's bad for your sanity. If you can't afford a switch, you can't afford Fibre Channel. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvsup3.freebsd.org
< said: > Is there any chance I could convince you to temporarily change the > entry for cvsup3 to point at cvsup4 until Garrett gets a chance to > take care of this? I was able to delete the contents of lost+found on that partition to temporarily free up several megabytes, which should be enough until I get back unless someone imports a new version of GCC. I do not see any errors in the most recent update log. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
cvsup3.freebsd.org
I am about to leave on vacation (as soon as I get rid of all this e-mail) for the rest of the week, and I noted that cvsup3 just ran out of disk space in the partition where the cvsup mirror itself is stored. I most likely won't be able to fix this until I get back on Monday. Fair warning. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adsl/pppoe no longer connecting on 5.1
< said: > Sounds like alloca() should simply be stricken from libc > on all architectures. Yes. (For values of `all' being `i386'.) > Might also be a good idea to begin removing uses of it. Not necessarily. There's nothing wrong, intrinsically, with using alloca(), although much but not all of the purpose has been subsumed by variable-length arrays which I think are in C99. One merely has to be aware that it is not part of Standard C (any more than a thousand other interfaces in FreeBSD) which must be implemented in the compiler; therefore, one cannot expect programs which expect alloca(3) to be available and have the standard semantics to work when compiled with a strictly conforming compiler. Most compilers do implement alloca(). -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adsl/pppoe no longer connecting on 5.1
< said: > Misbehaving in what way? CSTD=c99 causes gcc to use alloca() from > libc instead of its builtin version. Perhaps alloca() in libc is > broken -- any bugs in it would have been covered up by gcc until > now. alloca() in libc is *fundamentally* broken. Only the compiler can know the current state of the stack frame, and that information is not necessarily available to library functions. On some architectures it is not even possible for a library function to adjust its caller's stack frame, which is why alpha, ia64, and sparc64 don't have an alloca.S (nor an alloca.c for that matter). -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Apparent i386 alloca.S bug (was: adsl/pppoe no longerconnecting on 5.1)
< said: > builtin alloca() until we figure out how to fix the one in libc. It is fundamentally impossible to ``fix'' the alloca() implementation in libc. alloca() CANNOT be implemented that way. If GCC's builtin alloca() is disabled by requesting a strict Standard C environment (which is not appropriate for FreeBSD anyway), then alloca() is just an ordinary user symbol and programs expecting the implementation to supply it should simply fail. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nbufkv hang?
I just noticed my news server hanging in nbufkv state, apparently having hosed itself overnight (about 15 hours ago); expire was still running, although it was not the only process waiting. I can't find anything in the -current archives from this century. Any suggestions? FWIW, most of the filesystems on this machine use 64k/8k blocks. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: raidframe
< said: > FreeBSD 5.x series is slowly progressing, but is nowhere near to > production quality. As the things are currently, you simply waste > your time. I'm running an old 5.1-current and a more recent 5.1-beta of about a week ago in production as news servers and am reasonably pleased with the results. Other than the cvsup mirror I don't have any more intensive test workload than that. The 5.1-beta installation replaced a W2K Advanced Server running NNTPRelay, and so far it's stayed up three whole days, which is a hell of a lot longer than W2K ever did. 5.x is getting there. It has been stable enough for desktop use for a long time, and now the rest of the system is catching up. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Bad ACPI timer causes uninterruptible hang on boot?
I've been trying to figure out why my Intel SR2100 servers would not boot with ACPI enabled, hanging uninterruptibly after probing the ACPI timer. I experimented with disabling various subsystems, and came up with the following results: - With `pci_link' disabled, the boot gets as far as ``Device configuration complete'' before hanging. - With `timer' disabled, the boot gets all the way through. - With `bus', `children', or `all' disabled, the boot fails at mountroot, having failed to probe any devices. A verbose boot of the kernel with `timer' disabled shows the following. Note also that some of the thermal parameters are given as -1, which seems to confuse the thermal module. -GAWollman Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Thu Mar 13 12:58:29 EST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GRAPEVINE Preloaded elf kernel "/boot/kernel/kernel" at 0xc051f000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc051f0b4. Calibrating clock(s) ... i8254 clock: 1193098 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz Calibrating TSC clock ... TSC clock: 999722211 Hz Timecounter "TSC" frequency 999722211 Hz CPU: Intel Pentium III (999.72-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383fbff real memory = 1073676288 (1023 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00546000 - 0x3ffe7fff, 1068113920 bytes (260770 pages) avail memory = 1037578240 (989 MB) bios32: Found BIOS32 Service Directory header at 0xc00f6990 bios32: Entry = 0xfd85e (c00fd85e) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd7c0+0x397 pnpbios: Found PnP BIOS data at 0xc00f69c0 pnpbios: Entry = f:a934 Rev = 1.0 Other BIOS signatures found: Allocating major#253 to "net" null: Allocating major#252 to "pci" mem: Pentium Pro MTRR support enabled random: npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE31 pci_open(1):mode 1 addr port (0x0cf8) is 0x8070 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=00091166) pcibios: BIOS version 2.10 acpi0: power button is handled as a fixed feature programming model. acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_tz0: on acpi0 acpi_tz0: _CRT value is absurd, ignored (-217.-7C) acpi_tz0: _ACx value is absurd, ignored (-247.-7C) acpi_tz1: on acpi0 acpi_tz1: _CRT value is absurd, ignored (-217.-7C) acpi_tz1: _ACx value is absurd, ignored (-247.-7C) acpi_tz2: on acpi0 acpi_tz2: _CRT value is absurd, ignored (-217.-7C) acpi_tz2: _ACx value is absurd, ignored (-247.-7C) acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.IR1_ irq 0: [ 5 10] low,level,sharable 0.15.0 \\_SB_.LN12 irq 10: [ 5 10] low,level,sharable 0.3.0 \\_SB_.LN13 irq 11: [ 5 10] low,level,sharable 0.2.0 \\_SB_.LN1A irq 5: [ 5 10] low,level,sharable 0.6.0 \\_SB_.LN1B irq 0: [ 5 10] low,level,sharable 0.6.1 \\_SB_.LN1C irq 0: [ 5 10] low,level,sharable 0.6.2 \\_SB_.LN1D irq 0: [ 5 10] low,level,sharable 0.6.3 \\_SB_.LN17 irq 0: [ 5 10] low,level,sharable 0.7.0 \\_SB_.LN1B irq 0: [ 5 10] low,level,sharable 0.7.1 \\_SB_.LN1C irq 0: [ 5 10] low,level,sharable 0.7.2 \\_SB_.LN1D irq 0: [ 5 10] low,level,sharable 0.7.3 \\_SB_.LN18 irq 0: [ 5 10] low,level,sharable 0.8.0 \\_SB_.LN1D irq 0: [ 5 10] low,level,sharable 0.8.1 \\_SB_.LN1B irq 0: [ 5 10] low,level,sharable 0.8.2 \\_SB_.LN1C irq 0: [ 5 10] low,level,sharable 0.8.3 \\_SB_.LN19 irq 0: [ 5 10] low,level,sharable 0.9.0 \\_SB_.LN1C irq 0: [ 5 10] low,level,sharable 0.9.1 \\_SB_.LN1D irq 0: [ 5 10] low,level,sharable 0.9.2 \\_SB_.LN1B irq 0: [ 5 10] low,level,sharable 0.9.3 before setting priority for links \\_SB_.IR1_: interrupts: 510 penalty: 1860 1860 references: 1 priority: 0 \\_SB_.LN1B: interrupts: 510 penalty: 1860 1860 references: 4 priority: 0 \\_SB_.LN1C: interrupts: 510 penalty: 1860 1860 references: 4 priority: 0 \\_SB_.LN1D: interrupts: 510 penalty: 1860 1860 references: 4 priority: 0 \\_SB_.LN17: interrupts: 510 penalty: 1860 1860 references: 1 priority: 0 \\_SB_.LN18: interrupts: 510 penalty: 1860 1860 references: 1 priority: 0 \\_SB_.LN19: interrupts: 510 pena
Re: cvs commit: src/sys/vm vm_map.c vm_map.h vm_pageout.c
< said: > A real problem is that a swapped out process' uarea has to be > paged back in, even when no memory is available. I don't think > there's an easy way around that, given that you need the uarea and > kernel stack to handle the signal. But you don't, actually -- at least not to ``handle'' a SIGKILL. In that case, you should be able to simply destroy the process and free whatever swap it has been allocated without ever giving it control. So is the issue that we don't want to send SIGKILL too aggressively, and send some other signal to give the process a chance to exit gracefully? -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CFR: add widely accepted _ISOC99_SOURCE
< said: > What to do, if, say, C99 program want to use some POSIX functions from > lower (and not from higher) POSIX standard? Programmer error. Either it's a C99 program or it's an old-POSIX program; it cannot be both. > #define _GNU_SOURCE 1 > #define _ISOC99_SOURCE 1 > #define _POSIX_C_SOURCE 199506L > #define _XOPEN_SOURCE 500 > #define _LARGEFILE64_SOURCE 1 It is requesting contradictory namespaces, and getting what it deserves. It should not define any of these. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bash2 or devfs problem?
< There is no standard, other than Tenth Edition and Plan 9. Most > programs which use it expect it to behave like one or the other. s/one or the other/that/ -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bash2 or devfs problem?
< said: > Has anybody found out what the standards conformant thing is for /dev/fd ? There is no standard, other than Tenth Edition and Plan 9. Most programs which use it expect it to behave like one or the other. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
#warning must be protected by #if __GNUC__ in headers?
< said: > Does the use of #warning need to be protected by > #if __GNUC__ in FreeBSD header files? No, it needs to be replaced by the standard `#error' directive instead. I asked portmgr to do a run on the portsd cluster with this change to look for ports that mistakenly include this file, but I never heard back and portmgr is now busy doing the packages for 4.8. `#if __GNUC__' wouldn't help matters; every preprocessor has to read and interpret every preprocessor directive (so that `#else' and `#endif' can be recognized). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: typo in socreate() or i'm missing something
< said: > Interestingly, socreate() in Lite2 always does a can-wait malloc() so > our current soalloc(M_NOWAIT) does the same thing as Lite2 and is only > wrong if the FreeBSD change from can-wait to "can-wait-if p != 0" > change was needed and is still needed. When I initially revamped that code, I waited unconditionally and was rewarded with an appropriate panic for sleeping in interrupt context. I cannot speak as to whether it is still needed. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Any ideas why we can't even boot a i386 ?
< said: > Also, 386-core based chips are still in production (or have been in > the last year). It has only been very recently that the embedded > chips have transitioned to 486. Calling them, as others have, 10 > years obsolete is a bit of an overstatement... There is lots of obsolete technology that's still in production somewhere. It is no less trailing-edge for remaining available. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Any ideas why we can't even boot a i386 ?
< said: > I was evidently under the mistaken impression this was about nuts > and bolts. If we are to focus on window dressing, we are definitely > hozed. We focus on what's actually useful to the plurality of users. Support for a processor that was functionally obsolete ten years ago is not it. (If you want NetBSD, you know where to find it.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL question for id_function()
< said: > Interesting. I don't have that standard and wasn't aware of the > change. You do. It's available for free on the Web from opengroup.org. Free registration is required. Mike may still have some copies of the official guidebook to the standard, which includes the final text PDFs, which were donated by The Open Group. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL question for id_function()
< said: > FreeBSD violates POSIX in this respect. The 1003.1 standard > (section 2.5) requires pthread_t to be an arithmetic type. We are > non-compliant in the same way for almost all of the primary > thread-related types: Not so (with respect to those other types). XBD page 367: # All of the types shall be defined as arithmetic types of an # appropriate length, with the following exceptions: # # key_t # pthread_attr_t # pthread_barrier_t # pthread_barrierattr_t # pthread_cond_t # pthread_condattr_t # pthread_key_t # pthread_mutex_t # pthread_mutexattr_t # pthread_once_t # pthread_rwlock_t # pthread_rwlockattr_t # pthread_spinlock_t # trace_attr_t # trace_event_id_t # trace_event_set_t # trace_id_t SSWG-RT got a bit carried away with pthread_t, I think, because they define a comparison operation (pthread_equal()) even though such an operation is never necessary on arithmetic types (the `=' operator can be used for that purpose). We could define pthread_t as __intptr_t without making significant changes to the implementation. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
config files and includes.
< said: > What would be really cool is if more config files could > do 'includes' so that you could have a syslogd.local.conf > wher eall your local entries could be. In addition you could make it > look in /usr/local/etc/syslogd.conf for loging requirments for > packages. Well, it's a trivial part of XML but the syntax is twisted. The problem is that, particularly in the case of something like syslog.conf, you need to change the defaults, not just supplement them. Right now syslog has no concept of this (and changing the notation doesn't help without a complete rethink of the syslog.conf semantics). Worthwhile, but a lot of work for which nobody will be grateful (instead they will all complain that you changed the format of the file). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: _fpathconf() and __semctl() prototypes
< said: > _fpathconf() is quite different from __semctl. It is not a syscall. > It is a weak alias for fpathconf() which is prototyped normally in > . The prototype for fpathconf() should be turned into > a prototype for _fpathconf() by "namespace.h", but statvfs.c is missing > theinclude of so this doesn't happen. It's there in the version on my machine (rev. 1.2 by tjr dated 2002/09/06). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
C conformance.
< said: > Trying to use a compiler different from GCC I have found the folowing error > "/usr/include/sys/syslimits.h", line 42: Error: >[ISO 6.8]: Unknown preprocessing directive, '#warning'. It should probably be a #error instead. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Style fixups for proc.h
< union baz {
> int foo;
> struct frotz *gorp;
> } foobaz;
> #define foo foobaz.foo
Oops... What I meant to say:
union baz {
int bazu_foo;
struct frotz *bazu_gorp;
} foobaz;
#define foo foobaz.bazu_foo
With this emendation, my post will actually make sense.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Style fixups for proc.h
< said:
> I can't see what actual error is avoided by this warning.
It's a potential error -- if there were an actual error, it would be
an error and not a warning.
The issue is simple:
Say you have an object and a function declared in global scope:
int foo;
/* many lines of declarations */
/* perhaps this is even in a different file */
void bar(quux_t foo);
At some point, somebody changes the spelling of `foo' and adds a
preprocessor macro for compatibility:
union baz {
int foo;
struct frotz *gorp;
} foobaz;
#define foo foobaz.foo
What happens to the declaration of that function? Well,
void bar(quux_t foobaz.foo);
is a syntax error.
My personal opinion, which is different from what style(9) recommends,
is that parameter names should be omitted for all functions, EXCEPT
those with ambiguous parameter types. Most functions in the kernel
only operate on one object of a given type at a time, so even without
the names it is (or should be) obvious what the object is used for.
Some functions, however, take multiple objects of the same type (e.g.,
two different sorts of flags); in these cases some additional help may
be warranted.
In the case of user headers, if parameter names are included, they
MUST be protected, because they would otherwise be polluting the
user's namespace. Hence, most headers historically do not use
parameter names.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: removed?
< said: > Hmm..there must be something in the configure script that thinks we do. > http://bento.freebsd.org/errorlogs/alpha-5-latest/nvi-1.81.5_2.log It erroneously thinks that because we have the grantpt() function, we have SEWERS and SVID3 ptys. It needs to learn how to use the posix_openpt() function, or else revert back to the !HAVE_SYS5_PTY code (which is also broken: it doesn't search the full range of possible pty names). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dump -L and privilege
< said: > The other alternative would be to > create a setuid-to-root program that would take a snapshot and > chown it to the user that does dumps. I think this would actually be a useful feature for more than just dumps. I might want to allow some users (say, those in group `operator') to be able to create snapshots on their own, without allowing arbitrary mounting privileges. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: background fsck did not create lost+found
< said: > Unfortunately, I think it is possible that the unreferenced inode > has not been initialized, even though it is allocated in the inode > bitmap, so you could potentially get random junk. That is definitely true on UFS2, which I had forgotten. UFS2 inodes are only initialized when they are used. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: background fsck did not create lost+found
< said: > Would that be a big problem to allow some fsck option not to erase all > these softupdates-pending inodes, but to put them in lost+found as usual? It certainly couldn't be done with the background fsck, because background fsck works on a snapshot and not the running filesystem; thus, it cannot make any allocations -- it can only deallocate things. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
postfix equiv. of sendmail's -bH?
< said: > I upgraded my system last night to the latest -CURRENT and noticed a change > in the daily mail cleanup. Unfortunately, I'm not running sendmail, so now > I'm getting: If you can come up with a good (silent) way to detect whether `sendmail -bH' is unsupported, I'd be happy to add that to the script. It's supposed to be able to deal with that case, but right now it can only detect the case where sendmail is being used, but not the host status cache. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
getpwnam_r missing
< said: > #if defined(QT_THREAD_SUPPORT) && defined(_POSIX_THREAD_SAFE_FUNCTIONS) This conditional is erroneous, so you should definitely bug Troll Tech. It should instead read: #if defined(QT_THREAD_SUPPORT) && _POSIX_THREAD_SAFE_FUNCTIONS - 0 > 0 (We really should figure out how to implement the _r functions, because a POSIX.1-2001 system with threads is supposed to have them.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ep0 hard lockup during install
< said: > I just installed RC2 using a 3C574B with the 'ep' driver; worked just fine > aside from needing to re-roll kern.flp and mfsroot.flp to support OLDCARD. My 3C589D works just fine in 5-current with NEWCARD. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: revoke(2) redux...
< There is no way you can close the race between:
> revoke("/dev/ttyfoo");
> and
> open("/dev/ttyfoo");
> Not even in init(8). There is always the risk that another process
> opens the device between the two.
If that process belongs to root then it doesn't matter.
If that process belongs to the user who's logging in, then it doesn't
matter (the user can hose himself, but that's his own fault).
If that process belongs to someone else, then the permissions on the
device are set wrong, and that's a security problem that revoke()
isn't trying to fix.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
revoke(2) redux...
< said: > Isn't there a pretty obvious race between the revoke() and the open() ? To the extent that the race matters, it is obviated by making sure that only the current user has permission to open the device. If the user somehow manages to open a device that he owns anyway, it's his problem if doing so screws it up. revoke() was a POSIX invention; it replaces the older vhangup(). The problem with vhangup() was that it merely signalled the previous openers -- if they had a SIGHUP handler installed, they did not actually lose access to the device. AIX has an extension such as you suggest (they call it frevoke()). AIX also implements it for all vnodes, not just device-specials, so it is somewhat more general-purpose. The POSIX function was introduced for only one reason: to provide a secure replacement for vhangup() in the POSIX tty model. Thus, it is not fully general. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Port package on RC1
< said: > I'm wondering what it's doing because it isn't copying over ports > very fast. It's slow because it's creating lots of very small directories. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 80386 out of GENERIC
< said: > Was sysinstall around when 386 was new? Just curious what's changed since > then to make it bigger. The 80386 came out in 1986. FreeBSD 1.0 came out in 1994, and I don't think we even had sysinstall then. I did a lot of 386BSD work on a 386SX/16, which was already old by the time I got it. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw userland breaks again.
< said: > If people are reasonable with me, I am reasonable right back. If > people are unreasonable, they shouldn't expect me to be reasonable > in response. It's really that simple. As a FreeBSD developer, you are expected to be civil to your fellow developers at all times, as stated in the committers' rules. If you can't manage that, please find another project. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw userland breaks again.
< said: > Now you are forcing me to go to core. It's absolutely ridiculous and > you know it. Goddamn it, next time I won't even bother posting if all > I get is this sort of crap. All the better, if you refuse to be civil to your fellow developers. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Losing the battle with RC1
< said: > Thanks for pointing out the obvious! (Although I am confused by why it > wiped the root partition which is BEFORE swap.) Because it starts at the end of the specified partition and works its way backwards. (The hope is to preserve as much of the existing swap as possible, under the assumption that swap starts from the beginning.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: POSIX semaphores in FreeBSD-CURRENT
< said: > >http://www.freebsd.org/cgi/man.cgi?query=sem_open&apropos=0&sektion=0&manpath=SunOS+5.7&format=html BZZT! Appeal to irrelevant authority. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Posix Semaphores in -CURRENT
< said: > So apart from the leading slash character, nothing is mentioned about > embedded slashes in the semaphore name. What's the right behavior > for FreeBSD then? The reason why the standard is written that way was to allow for RTOS implementations which do not have a filesystem. A quality implementation should represent these objects in the filesystem when this is possible. The semaphore itself need not reside in the filesystem; the path name could be used only as a rendezvous point. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Posix Semaphores in -CURRENT
< said: > So, is there some mechanism I am missing? Is there a layer between the > application calling sem_open and the kernel receiving the parameters > that strips it down to the last component? If there is a higher level > involved here, why is the low-level ksem_create function worrying about > embedded '/' characters? I find this rather puzzling. Speaking as a standards person, I can state with some certainty that *the name of a POSIX semaphore is intended to have path name semantics*. It is not required to be an actual path name, but there is a clear expectation that a quality implementation will do so. The POSIX developers saw these IPC objects as being analogous to shared memory objects or fifos, and did not see a compelling reason to invent an entirely new namespace for them. Stevens actually suggests an implementation of named semaphores in which the semaphore is represented by a file which contains the name (``key'') of an SVID semaphore. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_fxp and pause packets (or, "I didn't need the network anyway")
< said: > I've noticed this too with fxp. It only happens while in ddb and I > thought it was my fault (I was debugging some networking problems). It happens when the NIC's receive queue fills up. When you're in DDB, the kernel is not answering network interrupts. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sys/file.h and POSIX
< said: > may != MUST. We do not pollute the name space. Providing additional > facilities pollutes the name space, breaking strictly conforming > programs. Not necessarily. The Standard reserves certain namespaces for the implementation's use. However, none of the examples people are complaining about are subject to such reservations. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Is this a known LOR?
lock order reversal 1st 0xc37e7a68 vnode interlock (vnode interlock) @ ../../../kern/vfs_subr.c:939 2nd 0xc043d720 vm page queue mutex (vm page queue mutex) @ ../../../vm/vm_kern.c:424 ident says: /sys/kern/vfs_subr.c: $FreeBSD: src/sys/kern/vfs_subr.c,v 1.419 2002/10/26 14:38:21 rwatson Exp $ /sys/vm/vm_kern.c: $FreeBSD: src/sys/vm/vm_kern.c,v 1.87 2002/08/25 00:22:31 alc Exp $ I have no idea what was happening when this happened as I was not near the console over the long weekend. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hi,a little question about DP2.
< said: > I don't know why the 'c' partition doesn't start at 0. > It is strange. For backwards compatibility, the FreeBSD 4.x kernel would fake up the partition tables so that they would look like old (pre-slicing) FreeBSD partition tables; i.e., the starting offset of the slice would be subtracted from all of the partition offsets on read and added back in on write. The disk partitioning subsystem in 5.x doesn't do this. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hi,a little question about DP2.
< said: > Actually it is the 'c' slice that is generally used to indicate the whole > disk. This is still the case in 5.0. However, I am unable to tell you what > 'd' used to represent. I am also clueless on this particular detail. No, the `c' partition usually indicates the whole FreeBSD slice. A very, very long time ago (before FreeBSD grew ``slices''), the `d' partition of the first slice with type 165 was used to describe the entire disk. Utilities like `fdisk' and `sysinstall' knew about this long after it ceased being magic. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Are SysV semaphores thread-safe on CURRENT?
< said: > Is this the recommended method of preventing these problems? The recommended method of preventing these problems generally is to use POSIX semaphores (or other POSIX synchronization mechanisms appropriate to threaded programs. However, the code to implement process-shared POSIX semaphores is still experimental. The problem with System V semaphores is that there is no way to poll their status while still polling the process's file descriptors. This could be fixed by introducing a new kqueue filter, but the semantics of System V semaphores are difficult to emulate. Depending on the semantics you require, a semaphore may be implemented using a pipe or fifo, or by using file or record locking. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CPUTYPE cr*p (Was: [kris@FreeBSD.org: 5.0-CURRENT build failure of ports you maintain])
< said: > It's described in the file itself. Can you please file a PR about the > missing manpage documentation? make.conf is no longer installed in -current. A user trying to understand why some glop is being added automatically to CFLAGS will probably not think to read /usr/share/examples/etc/make.conf. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Asking for tester (small patch to chown(8)/chgrp(1))
< said: > I'm concerned about the used character: "-r" is similiar to "-R" Yes, `-r' would be a very poor choice for the reason you state. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sleep(1) behavior
< said: > So "sleep -1" should sleep for ~0UL seconds? And should usage() ever be > called then? Well, the standard says that anything might happen as a result of `sleep -- -1'. I'm just pointing out why the standard says so. (This sort of thing is what is referred to in the standards jargon as ``quality of implementation'' -- the standard doesn't require an error for this case, because doing so would require implementations to partially reimplement strtoul() in the sleep utility, just to validate the argument. The standard does not prohibit an implementor from going to this effort, however, and if you are already using strtod() instead of strtoul(), there's no additional effort required.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
