Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
Wrong, strtol() can set errno in two cases, when the value is outside the range of representable values or when no conversion could be performed. well 'natch. it's trying to do math.h style hacks and overloads errno. iirc those sorts of things stem from V6/V7 on the PDP/11 when you may have had no FPU and 32 bit ops were library functions. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
From: Stefan Farfeleder [EMAIL PROTECTED] errno is meaningful for syscalls after an error (the original message). The fact that other functions also dink with errno is not relevant to that statement. I read boyd's statement as a contradiction to Jacques' one (only after syscall error vs. after library call error). some libc functions do mangle errno, but only after an error. in my terse statement the intention was to affirm that errno is meaningless unless an error has ocurred (a syscall being the simplest case, while random other libc calls may behave in the same way). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
i see that there some doubt about whether running lots of shell scripts ever happens. what happens when you use make? lots of shells get run and they run small (one line?) scripts. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
That's a more interesting result and more comparable to Drew's test. It doesn't necessarily invalidate Drew's results - /bin/sh has 3 shared libraries and is locale-aware whereas /usr/bin/test has 1 shared library and doesn't rely on the locale. /usr/bin/true is also significantly smaller (implying less relocation requirements). /bin/sh could reasonably be expected to take longer to startup then /usr/bin/test. another can of worms. various shells have test, true and false built in. so, you have to be very careful in writing a shell comparision benchmark. to complicate matters, ksh (statically linked) has _always_ been faster than sh. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
From: Jacques A. Vidrine [EMAIL PROTECTED] The application is broken. You must only check errno if you get an error indication from the library call. errno is only meaningful after a syscall error. it is also well known that stdio uses isatty(3) (or equivelant) that may set errno to ENOTTY. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
So.. forking a dynamic sh is roughly 40% more expensive than forking a static copy of sh. This is embarrassing. read the original paper carefully: http://citeseer.nj.nec.com/cache/papers/cs/3066/http:zSzzSzswt-www.informatik.uni-hamburg.dezSz~1friedrizSzsvzSzreferenceszSzShared_Libraries_In_Sun_OS.pdf/gingell87shared.pdf it's conclusions state that they are slower. this was the _original paper_ that announced the damn things. ___ [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
how about no copy of vi, or termcap and one copy of ed? ___ [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
From: Richard Coleman [EMAIL PROTECTED] Is this where we start swapping stories about when I was a young sysadmin, we didn't need no stinkin vi. We used ed and liked it!. :-) the point is that when you really want your valuable data back (without resorting to backups) a small, simple toolkit is superior to abitrary and gratuitous complexity. or you could goto fonfon; ___ [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
From: Peter Jeremy [EMAIL PROTECTED] As for overloading the 't' bit, I don't believe it's ever been used for anything else on executable files. directories ___ [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
From: William Josephson [EMAIL PROTECTED] People at Berkeley (and elsewhere) have done user studies to try to quantify this sort of thing. It is pretty clear that with modern hardware, most failures are due to human error. That's not to say that hardware and software faults aren't real problems, too, but it is more common that someone, say, pulls the wrong drive from the RAID-5 array, resulting in an unnecessary double disk fault. that means your raid 5 is bust. i've seen raid 5 fail and it just picks another disk in the 'free' pool like nothing has happened. a study? it's bleeding obvious. ___ [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
From: Dimitry Andric [EMAIL PROTECTED] % sudo ldd /sbin/init /sbin/init: libutil.so.3 = /lib/libutil.so.3 (0x28074000) libcrypt.so.2 = /lib/libcrypt.so.2 (0x2807f000) libc.so.5 = /lib/libc.so.5 (0x28097000) Yes, working fine here. What should the problem be? the day /lib gets smashed. you're building a house of cards. once, if /etc/init and /bin/sh and some other pieces where in place a smashed file-system could be easily fixed. now you have to have 3 shared libs and a viable /lib. do you want systems that work? or houses of cards? ___ [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
From: Christopher Vance [EMAIL PROTECTED] Personally, I think init should be static, and can't think of any way it would benefit from shared libraries. plan 9 has everything static. the kernel compiles in about 20 seconds or less -- no compression -- and you can boot it off a floppy. if i can sit in /sys/src and type: mk install and have everything re-built (and i could do it for all the supported architectures) in minutes i have eliminated unnecessary complexity. if it's not there, it can't break. btw: say hi to maltby for me. ___ [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
From: Steve Kargl [EMAIL PROTECTED] This is only marginally different than /sbin/init getting smashed. If the root partition develops problems, you need to restore for tape. tape? who uses tape? optical, my son. brother, can you spare a TU-16? ___ [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
From: Tim Kientzle [EMAIL PROTECTED] Many of us here have been hamstrung by systems that didn't provide a static fallback. I've personally been bitten by unrecoverable Linux and Solaris systems due to hosed shared libraries. bingo. a small set of tools will usually save you. vi(1) is out of the question because it is too complex. init, sh, echo, cat, ed, sed, fsck (and 'once upon a time' fsdb) should do it. remove dynamic linking and you remove Yet Another Band-Aid. the kernel should be able to page stuff right which should eliminate the need for this folly. ___ [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
plan9 doesn't count. It's so minimalistic, it's useless. well, try to think about non-minimalism when you're trying to track down a kernel bug in a zillion SLOC ... ___ [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
From: Bruce M Simpson [EMAIL PROTECTED] During my time in an investment bank, installations were usually hosed in this way by human error (systems administrators removing a file by accident, etc) ... yup, it's rare i've seen flakey h/w. but i do remember one sysadmin (when i was a contract sysadmin) who on day 2 chown'd the whole source tree to himself on a development m/c. ugly. there were backups but 'that would be too costly [in time]' to do a clean restore. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
