From owner-freebsd-hackers Sun Oct 15 00:10:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA07926 for hackers-outgoing; Sun, 15 Oct 1995 00:10:18 -0700 Received: from csc.canberra.edu.au (csc.canberra.edu.au [137.92.1.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id AAA07913 for ; Sun, 15 Oct 1995 00:10:08 -0700 Received: from student.canberra.edu.au by csc.canberra.edu.au (5.65/1.35) id AA00870; Sun, 15 Oct 95 17:09:27 +1000 Received: by student.canberra.edu.au (5.x/SMI-SVR4) id AA19920; Sun, 15 Oct 1995 17:09:23 +1000 Date: Sun, 15 Oct 1995 17:09:22 +1000 (EST) From: "Gasparovski / Daniel (ISE)" To: Warner Losh Cc: hackers@freebsd.org Subject: Re: IPX now available Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk > : % bg >& make.out > : [1]+ make world & > : % > : > : Hurrah, the output is now redirected to make.out! > > I'd give half my left kidney for something like this! (Pure software > already had my right kidney) Why can't this be done in the shell? eg: have the shell fork off the process, give it a pty as controlling terminal which will be handled by the shell, and by default show it's output on the user's tty. Then, if a "bg >& make.out" is given, have the shell open make.out and start writing the output there instead of the tty. It's not the most ideal solution, for example "ls" won't do the right thing, but it's good enough for most, if not all, situations. Your best bet would be to make such a suggestion to the zsh mailing list, since zsh is a wonderfully rich shell which can already handly things like echo spam > file1 > file2 (which also needs shell intervention), and it's still actively being developed by a very talented pool of programmers. Dan ... [ Danny Gasparovski | Mortified by the lack of conscience ] [ u923168@student.canberra.edu.au | Our sanctity bears no relevance ] [ University of Canberra, Australia | Insignificant is our existence ] [ Bolt Thrower, "The IVth Crusade" -> | Hear the litany of life's persistence ] From owner-freebsd-hackers Sun Oct 15 01:14:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA13138 for hackers-outgoing; Sun, 15 Oct 1995 01:14:04 -0700 Received: from pancake.remcomp.fr (root@pancake.remcomp.fr [194.51.30.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id BAA13118 for ; Sun, 15 Oct 1995 01:13:54 -0700 Received: (from didier@localhost) by aida.org (8.6.12/8.6.9) id IAA00264; Sun, 15 Oct 1995 08:55:52 +0100 Date: Sun, 15 Oct 1995 08:55:52 +0100 (MET) From: Didier Derny To: hackers@freebsd.org Subject: noise Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Hi I continuously hear a noise on my loudspeakers when I'm typing or when the hard disk is working. I dont know why I get this noise with FreeBSD. I've never that kind of problem with mdos. I'm using a soundblaster 16 with ASP. I can do any test you want to solve this problem. Thanks for your help -- Didier Derny didier@aida.org From owner-freebsd-hackers Sun Oct 15 01:14:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA13143 for hackers-outgoing; Sun, 15 Oct 1995 01:14:05 -0700 Received: from pancake.remcomp.fr (root@pancake.remcomp.fr [194.51.30.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id BAA13119 for ; Sun, 15 Oct 1995 01:13:57 -0700 Received: (from didier@localhost) by aida.org (8.6.12/8.6.9) id JAA00281; Sun, 15 Oct 1995 09:08:11 +0100 Date: Sun, 15 Oct 1995 09:08:11 +0100 (MET) From: Didier Derny To: hackers@freebsd.org Subject: crash while running xanim Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk My computer crashed while I was playing a large .avi file (robroy.avi from the Windows 95 cdrom). I found these messages in /var/log/messages: swap_pager: out of space process 302 killed by vm_fault -- out of swap. the computer froze then rebooted. I have been unable to reboot with the same kernel. Each time I try to reboot it told me that the FPU was not working and that he was unable to reset the computer so he tried to halt the cpu After having switched off my computer, waited 2 minutes and then restarted on an old kernel I found that many files I was not working on were lost. tell me If you want me to do some tests. Thanks for your help -- Didier Derny didier@aida.org From owner-freebsd-hackers Sun Oct 15 01:20:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA13668 for hackers-outgoing; Sun, 15 Oct 1995 01:20:51 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA13657 ; Sun, 15 Oct 1995 01:20:44 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA18411; Sun, 15 Oct 1995 09:20:40 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA06128; Sun, 15 Oct 1995 09:20:40 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA17881; Sun, 15 Oct 1995 08:52:28 +0100 From: J Wunsch Message-Id: <199510150752.IAA17881@uriah.heep.sax.de> Subject: Re: lint To: freebsd-hackers@FreeBSD.org Date: Sun, 15 Oct 1995 08:52:27 +0100 (MET) Cc: davidg@FreeBSD.org (David Greenman), dyson@FreeBSD.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510142250.IAA28055@godzilla.zeta.org.au> from "Bruce Evans" at Oct 15, 95 08:50:34 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1856 Sender: owner-hackers@FreeBSD.org Precedence: bulk As Bruce Evans wrote: > > >The newly-built lint buried another bogon out of the depths of the > >header mishmash: we've got a name clash for struct pmap! David? John? I'm wondering about your opinions about struct pmap... > One way to find more bogons than you want to know about is to include > all headers. Another way is to change all typedefs in headers to ones > that are allowed by standards but weird. Portable applications should > still compile cleanly with maximal warnings enabled. The first thing is what i did. I've tossed all the header file #includes and the external declarations out of those files into a single source, and ran it through lint. I've only been using those files that declare external symbols, and in case of the sys/ directory only those that declare things for the !KERNEL case. (List of broken sys/ header files: lodef.h, device.h, rlist.h, systm.h, tprintf.h -- all their function declarations should be #ifdef'ed for KERNEL.) This should ideally yield the interface declarations for libc. Not all of our headers are already self-contained. I need the following list of ``prerequisite headers'': #include #include #include #include #include #include #include Failing to declare them on top will cause several headers to fall over. The rpc/ case is the most iffiest: exactly _this_ sequence is needed, and this is not very obvious. It's not documented in the man pages, unlike the that's often mentioned as a prerequisite in many man pages, or and that are mentioned in the resolver(3) man page. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Oct 15 02:35:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA19312 for hackers-outgoing; Sun, 15 Oct 1995 02:35:27 -0700 Received: from nanolon.gun.de (nanolon.gun.de [192.109.159.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA19297 for ; Sun, 15 Oct 1995 02:35:19 -0700 Received: (from uucp@localhost) by nanolon.gun.de (8.6.8.1/8.6.6) with UUCP id KAA15169 for hackers@freebsd.org; Sun, 15 Oct 1995 10:35:13 +0100 Received: from knobel.gun.de (localhost [127.0.0.1]) by knobel.gun.de (8.6.12/8.6.12) with SMTP id KAA01443 for ; Sun, 15 Oct 1995 10:34:27 +0100 Date: Sun, 15 Oct 1995 10:34:27 +0100 (MET) From: Andreas Klemm To: hackers@freebsd.org Subject: who has Motif and could package some html editors Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Hi ! I'm missing X11 html editors in the package/port section. The html editors I saw need Motif. Unfortunately I don't have Motif for FreeBSD. So it would be very nice, if a kind soul could make the port !!! xhtml and ASHE are on my wishlist. Maybe there are some other good html editors out there ... Thanks Andreas /// -- $$ apsfilter - magic print filter 4lpd @home : andreas@knobel.gun.de $$ ftp://sunsite.unc.edu @work : andreas@sunny.wup.de $$ /pub/Linux/system/Printing/aps-491.tgz knobel: >>> powered by FreeBSD <<< From owner-freebsd-hackers Sun Oct 15 02:57:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA19808 for hackers-outgoing; Sun, 15 Oct 1995 02:57:21 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA19802 ; Sun, 15 Oct 1995 02:57:11 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA13687; Sun, 15 Oct 1995 19:52:54 +1000 Date: Sun, 15 Oct 1995 19:52:54 +1000 From: Bruce Evans Message-Id: <199510150952.TAA13687@godzilla.zeta.org.au> To: freebsd-hackers@freebsd.org, j@uriah.heep.sax.de Subject: Re: lint Cc: davidg@freebsd.org, dyson@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >The first thing is what i did. I've tossed all the header file >#includes and the external declarations out of those files into a >single source, and ran it through lint. I've only been using those >files that declare external symbols, and in case of the sys/ directory >only those that declare things for the !KERNEL case. (List of broken >sys/ header files: lodef.h, device.h, rlist.h, systm.h, tprintf.h -- >all their function declarations should be #ifdef'ed for KERNEL.) This >should ideally yield the interface declarations for libc. lodef.h seems to be a misspelling. device.h has never really been used. Machine-dependent stuff in isa_device.h and stuff in devconf.h is used instead. device.h is included in only two places in the kernel: - in init_main.c where it isn't used - in si.c where it is used to waste some space in struct si_softc and to print the wrong unit number in an error message. rlist.h is broken. systm.h is only supposed to be included in the kernel. tprintf.h seems pointless. It only declares a couple of printf-like functions and is only included once in the kernel. >Not all of our headers are already self-contained. I need the >following list of ``prerequisite headers'': >#include >#include >#include >#include >#include >#include >#include >Failing to declare them on top will cause several headers to fall >over. >The rpc/ case is the most iffiest: exactly _this_ sequence is needed, The 4.4lite2 style guide says to include only one of param.h and types.h. I found another unobvious prerequisite: must be included before . This is probably a bug in the nfsv3 code. used to be self contained, and lsof expects it to be self-contained. Bruce From owner-freebsd-hackers Sun Oct 15 03:21:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA20352 for hackers-outgoing; Sun, 15 Oct 1995 03:21:05 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA20340 for ; Sun, 15 Oct 1995 03:21:00 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id DAA17388; Sun, 15 Oct 1995 03:19:39 -0700 To: "Gasparovski / Daniel (ISE)" cc: Warner Losh , hackers@freebsd.org Subject: Re: IPX now available In-reply-to: Your message of "Sun, 15 Oct 1995 17:09:22 +1000." Date: Sun, 15 Oct 1995 03:19:39 -0700 Message-ID: <17386.813752379@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > eg: have the shell fork off the process, give it a pty as controlling > terminal which will be handled by the shell, and by default show it's > output on the user's tty. Then, if a "bg >& make.out" is given, have the > shell open make.out and start writing the output there instead of the tty. > > It's not the most ideal solution, for example "ls" won't do the right > thing, but it's good enough for most, if not all, situations. Until you run out of PTYs.. :-) Really, (ab)using PTYs in such a fashion would almost certainly predicate reimplimenting them to be truly dynamic. If you need a PTY every time anyone needs to perform a "splice" operation then you're going to run out of them PDQ. It also grossly violates my sense of esthetics.. :-) Truly, if you think of the problem as implementing something more like a "cross bar" switch with a fairly sophisicated model of data "sources" and "sinks" then you're starting to talk more my language. Make any file dependency from a process refer to an object that can be reassigned, age and die, etc and you're really piquing my interest.. :-) > echo spam > file1 > file2 > > (which also needs shell intervention), and it's still actively being > developed by a very talented pool of programmers. Hmmm. I've heard a fair bit about zsh, yes. Jordan From owner-freebsd-hackers Sun Oct 15 03:25:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA20486 for hackers-outgoing; Sun, 15 Oct 1995 03:25:07 -0700 Received: from nanolon.gun.de (nanolon.gun.de [192.109.159.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA20470 for ; Sun, 15 Oct 1995 03:24:52 -0700 Received: (from uucp@localhost) by nanolon.gun.de (8.6.8.1/8.6.6) with UUCP id LAA23498 for hackers@freebsd.org; Sun, 15 Oct 1995 11:24:37 +0100 Received: from knobel.gun.de (localhost [127.0.0.1]) by knobel.gun.de (8.6.12/8.6.12) with SMTP id LAA07714 for ; Sun, 15 Oct 1995 11:21:08 +0100 Date: Sun, 15 Oct 1995 11:21:08 +0100 (MET) From: Andreas Klemm To: hackers@freebsd.org Subject: can't compile GENERIC kernel because of undefined symbols Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Hi ! I already had the (I think same) problem, that I couldn't link a kernel successfully, because some things were out of sync (old kernel libs, newer kernel sources due to supping). A 'make clean' in /sys cured the problem... But now I have again the same problem, but nothing helps. I did a make world yesterday in single user mode. Then a make clean in /sys But everytime I get those messages: loading kernel cd9660_lookup.o: Undefined symbol `_isonum_711' referenced from text segment cd9660_lookup.o: Undefined symbol `_isonum_711' referenced from text segment cd9660_lookup.o: Undefined symbol `_isonum_711' referenced from text segment cd9660_lookup.o: Undefined symbol `_isonum_711' referenced from text segment cd9660_node.o: Undefined symbol `_isonum_733' referenced from text segment cd9660_node.o: Undefined symbol `_isonum_733' referenced from text segment cd9660_node.o: Undefined symbol `_isonum_711' referenced from text segment cd9660_node.o: Undefined symbol `_isonum_711' referenced from text segment cd9660_node.o: Undefined symbol `_isonum_711' referenced from text segment cd9660_node.o: Undefined symbol `_isonum_711' referenced from text segment cd9660_node.o: Undefined symbol `_isonum_711' referenced from text segment cd9660_node.o: More undefined symbol _isonum_711 refs follow cd9660_node.o: Undefined symbol `_isonum_723' referenced from text segment cd9660_node.o: Undefined symbol `_isonum_723' referenced from text segment cd9660_node.o: Undefined symbol `_isonum_733' referenced from text segment cd9660_rrip.o: Undefined symbol `_isonum_731' referenced from text segment cd9660_rrip.o: Undefined symbol `_isonum_731' referenced from text segment cd9660_rrip.o: Undefined symbol `_isonum_731' referenced from text segment cd9660_rrip.o: Undefined symbol `_isonum_731' referenced from text segment cd9660_rrip.o: Undefined symbol `_isonum_733' referenced from text segment cd9660_rrip.o: Undefined symbol `_isonum_733' referenced from text segment cd9660_rrip.o: Undefined symbol `_isonum_733' referenced from text segment cd9660_rrip.o: Undefined symbol `_isonum_733' referenced from text segment cd9660_rrip.o: Undefined symbol `_isonum_733' referenced from text segment cd9660_rrip.o: Undefined symbol `_isonum_733' referenced from text segment cd9660_rrip.o: More undefined symbol _isonum_733 refs follow cd9660_vfsops.o: Undefined symbol `_isonum_723' referenced from text segment scsi_base.o: Undefined symbol `_memcmp' referenced from text segment if_ze.o: Undefined symbol `_memcmp' referenced from text segment if_ze.o: Undefined symbol `_memcmp' referenced from text segment if_ze.o: Undefined symbol `_memcmp' referenced from text segment if_zp.o: Undefined symbol `_memcmp' referenced from text segment *** Error code 1 Stop. The way I make a new kernel ?!... config GENERIC cd compile/GENERIC make depend && make ... linker complains ... cd /sys && make clean cd compile/GENERIC && make ... same linker problems ... I'm running a fresh -stable Thanks for any help. Currently I'm not able to compile a kernel successfully. Andreas /// -- $$ apsfilter - magic print filter 4lpd @home : andreas@knobel.gun.de $$ ftp://sunsite.unc.edu @work : andreas@sunny.wup.de $$ /pub/Linux/system/Printing/aps-491.tgz knobel: >>> powered by FreeBSD <<< From owner-freebsd-hackers Sun Oct 15 03:54:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA21022 for hackers-outgoing; Sun, 15 Oct 1995 03:54:27 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA21017 for ; Sun, 15 Oct 1995 03:54:25 -0700 Received: from exalt.x.org by expo.x.org id AA07462; Sun, 15 Oct 95 06:53:53 -0400 Received: from localhost by exalt.x.org id GAA03600; Sun, 15 Oct 1995 06:53:52 -0400 Message-Id: <199510151053.GAA03600@exalt.x.org> To: hackers@freefall.FreeBSD.org Subject: A couple problems in FreeBSD 2.1.0-950922-SNAP Date: Sun, 15 Oct 1995 06:53:52 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk Sorry if this shows up twice. The one I sent last night hasn't come back yet, don't know if it got lost in the ether. 1) % man -k rune EUC(4) - EUC encoding of runes UTF2(4) - Universal character set Transformation Format encoding of runes mbrune(3), mbrrune(3), mbmb(3) - multibyte rune support for C setrunelocale(3), setinvalidrune(3), sgetrune(3), sputrune(3) - rune support for C %man setrunelocale No manual entry for setrunelocale 2) If I create a file that has extended ASCII (ISO8859-1) characters in the name, ls always substitues a '?' for the non-ASCII characters. Note that ls on, e.g. SVR4, does not do this I looked at the source for ls and I see that the conversion occurs when -q is specified (the default in any event). The FreeBSD ls man page says: -q Force printing of non-graphic characters in file names as the character `?'; this is the default when output is to a terminal. and just for reference the SVR4 man page says: -q Force printing of non-printable characters in file names as the character question mark (?). All multibyte characters are considered printable. So I think the test isprint in ls really ought to be isgraph instead. But just fixing ls isn't enough. The default table of character types in libc/locale/table.c isn't populated well enought to handle the whole ISO8859-1 character set. The following patch fixes ls, libc, and also fixes some bugs in mklocale's lt_LN LC_CTYPE template. *** bin/ls/util.c.orig Sat Oct 14 15:55:03 1995 --- bin/ls/util.c Sat Oct 14 17:02:00 1995 *************** *** 33,39 **** * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * ! * $Id: util.c,v 1.4 1994/10/09 15:25:23 ache Exp $ */ #ifndef lint --- 33,39 ---- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * ! * $Id: util.c,v 1.4 1994/10/09 15:25:23 ache Exp mumble$ */ #ifndef lint *************** *** 61,67 **** while (len--) { ch = *src++; ! *dest++ = isprint(ch) ? ch : '?'; } } --- 61,67 ---- while (len--) { ch = *src++; ! *dest++ = isgraph(ch) ? ch : '?'; } } *** lib/libc/locale/table.c.orig Sat Oct 14 16:24:22 1995 --- lib/libc/locale/table.c Sat Oct 14 17:00:40 1995 *************** *** 35,41 **** */ #if defined(LIBC_SCCS) && !defined(lint) ! static char sccsid[] = "@(#)table.c 8.1 (Berkeley) 6/27/93"; #endif /* LIBC_SCCS and not lint */ #include --- 35,41 ---- */ #if defined(LIBC_SCCS) && !defined(lint) ! static char sccsid[] = "@(#)table.c 8.1 (Berkeley) 6/27/93"; mumble #endif /* LIBC_SCCS and not lint */ #include *************** *** 86,91 **** --- 86,123 ---- _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, /*78*/ _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, _P|_R|_G, _P|_R|_G, _P|_R|_G, _P|_R|_G, _C, + /*80*/ _C, _C, _C, _C, + _C, _C, _C, _C, + /*88*/ _C, _C, _C, _C, + _C, _C, _C, _C, + /*90*/ _C, _C, _C, _C, + _C, _C, _C, _C, + /*98*/ _C, _C, _C, _C, + _C, _C, _C, _C, + /*a0*/ _S, _P|_R|_G, _P|_R|_G, _P|_R|_G, + _P|_R|_G, _P|_R|_G, _P|_R|_G, _P|_R|_G, + /*a8*/ _P|_R|_G, _P|_R|_G, _P|_R|_G, _P|_R|_G, + _P|_R|_G, _P|_R|_G, _P|_R|_G, _P|_R|_G, + /*b0*/ _P|_R|_G, _P|_R|_G, _P|_R|_G, _P|_R|_G, + _P|_R|_G, _P|_R|_G, _P|_R|_G, _P|_R|_G, + /*b8*/ _P|_R|_G, _P|_R|_G, _P|_R|_G, _P|_R|_G, + _P|_R|_G, _P|_R|_G, _P|_R|_G, _P|_R|_G, + /*c0*/ _U|_R|_G, _U|_R|_G|_A, _U|_R|_G|_A, _U|_R|_G|_A, + _U|_R|_G|_A, _U|_R|_G|_A, _U|_R|_G|_A, _U|_R|_G|_A, + /*c8*/ _U|_R|_G|_A, _U|_R|_G|_A, _U|_R|_G|_A, _U|_R|_G|_A, + _U|_R|_G|_A, _U|_R|_G|_A, _U|_R|_G|_A, _U|_R|_G|_A, + /*d0*/ _U|_R|_G|_A, _U|_R|_G|_A, _U|_R|_G|_A, _U|_R|_G|_A, + _U|_R|_G|_A, _U|_R|_G|_A, _U|_R|_G|_A, _P|_R|_G, + /*d8*/ _U|_R|_G|_A, _U|_R|_G|_A, _U|_R|_G|_A, _U|_R|_G|_A, + _U|_R|_G|_A, _U|_R|_G|_A, _U|_R|_G|_A, _L|_R|_G|_A, + /*e0*/ _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, + _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, + /*e8*/ _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, + _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, + /*f0*/ _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, + _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, _P|_R|_G, + /*f8*/ _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, + _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A, _L|_R|_G|_A }, { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, *** usr.bin/mklocale/data/lt_LN.ISO8859-1.orig Sat Oct 14 16:00:43 1995 --- usr.bin/mklocale/data/lt_LN.ISO8859-1 Sat Oct 14 16:15:43 1995 *************** *** 11,22 **** CONTROL 0x00 - 0x1f 0x7f - 0x9f DIGIT '0' - '9' GRAPH 0x21 - 0x7e 0xa0 - 0xff ! LOWER 'a' - 'z' 0xe0 - 0xff ! PUNCT 0x21 - 0x2f 0x3a - 0x40 0x5b - 0x60 0x7b - 0x7e 0xa1 - 0xbf SPACE 0x09 - 0x0d 0x20 0xa0 ! UPPER 'A' - 'Z' 0xc0 - 0xde ! XDIGIT 'a' - 'f' 'A' - 'F' ! BLANK ' ' '\t' 0xa0 PRINT 0x20 - 0x7e 0xa0 - 0xff # IDEOGRAM # SPECIAL --- 11,23 ---- CONTROL 0x00 - 0x1f 0x7f - 0x9f DIGIT '0' - '9' GRAPH 0x21 - 0x7e 0xa0 - 0xff ! LOWER 'a' - 'z' 0xdf - 0xf6 0xf8 - 0xff ! PUNCT 0x21 - 0x2f 0x3a - 0x40 0x5b - 0x60 0x7b - 0x7e 0xa1 - 0xbf 0xd7 0xf7 SPACE 0x09 - 0x0d 0x20 0xa0 ! UPPER 'A' - 'Z' 0xc0 - 0xd6 0xd8 - 0xde ! XDIGIT '0' - '9' 'a' - 'f' 'A' - 'F' ! # only one true blank in 8859-1 ! BLANK 0x20 PRINT 0x20 - 0x7e 0xa0 - 0xff # IDEOGRAM # SPECIAL *************** *** 24,35 **** MAPLOWER <'A' - 'Z' : 'a'> MAPLOWER <'a' - 'z' : 'a'> ! MAPLOWER <0xc0 - 0xdd : 0xe0> ! MAPLOWER <0xe0 - 0xff : 0xe0> MAPUPPER <'A' - 'Z' : 'A'> MAPUPPER <'a' - 'z' : 'A'> ! MAPUPPER <0xc0 - 0xdd : 0xc0> ! MAPUPPER <0xe0 - 0xff : 0xc0> TODIGIT <'0' - '9' : 0> TODIGIT <'A' - 'F' : 10> TODIGIT <'a' - 'f' : 10> --- 25,41 ---- MAPLOWER <'A' - 'Z' : 'a'> MAPLOWER <'a' - 'z' : 'a'> ! MAPLOWER <0xc0 - 0xd6 : 0xe0> ! MAPLOWER <0xd8 - 0xde : 0xe0> ! MAPLOWER <0xdf - 0xf6 : 0xe0> ! MAPLOWER <0xf8 - 0xfe : 0xe0> ! MAPUPPER <'A' - 'Z' : 'A'> MAPUPPER <'a' - 'z' : 'A'> ! MAPUPPER <0xc0 - 0xd6 : 0xc0> ! MAPUPPER <0xd8 - 0xde : 0xc0> ! MAPUPPER <0xdf - 0xf6 : 0xc0> ! MAPUPPER <0xf8 - 0xfe : 0xc0> TODIGIT <'0' - '9' : 0> TODIGIT <'A' - 'F' : 10> TODIGIT <'a' - 'f' : 10> From owner-freebsd-hackers Sun Oct 15 05:29:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA23003 for hackers-outgoing; Sun, 15 Oct 1995 05:29:24 -0700 Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA22986 for ; Sun, 15 Oct 1995 05:29:21 -0700 Received: (from root@localhost) by sbstark.cs.sunysb.edu (8.6.12/8.6.9) with UUCP id IAA13877; Sun, 15 Oct 1995 08:27:31 -0400 Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.6.11/8.6.9) id IAA19250; Sun, 15 Oct 1995 08:28:53 -0400 Date: Sun, 15 Oct 1995 08:28:53 -0400 From: Gene Stark Message-Id: <199510151228.IAA19250@starkhome.cs.sunysb.edu> To: Thomas David Rivers Cc: hackers@freebsd.org In-reply-to: Thomas David Rivers's message of Sat, 14 Oct 1995 22:45:42 -0400 Subject: Recording from SB16 in 2.0.5? References: <45qhr2$i9n@starkhome.cs.sunysb.edu> Sender: owner-hackers@freebsd.org Precedence: bulk >Has anyone been successful at recording sound with the sound-blaster-16 >driver in 2.0.5? Not in 2.0.5, but in -stable it works OK with NAS, vmix, or just catting /dev/audio. - Gene From owner-freebsd-hackers Sun Oct 15 05:43:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA23414 for hackers-outgoing; Sun, 15 Oct 1995 05:43:49 -0700 Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA23408 for ; Sun, 15 Oct 1995 05:43:44 -0700 Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id EAA00393; Sun, 15 Oct 1995 04:45:05 -0400 From: Peter Dufault Message-Id: <199510150845.EAA00393@hda.com> Subject: Re: Problems with remote Netscape2.0.. To: davidg@Root.COM Date: Sun, 15 Oct 1995 04:45:04 -0400 (EDT) Cc: combssf@salem.ge.com, hackers@freebsd.org, ache@astral.msk.su In-Reply-To: <199510130729.AAA00690@corbin.Root.COM> from "David Greenman" at Oct 13, 95 00:29:13 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 973 Sender: owner-hackers@freebsd.org Precedence: bulk > > >I've seen the same thing, and not yet been able to figure it out. It's not > >just with FreeBSD, I've seen it on my Sparc at work while trying to display > >on my FBSD box at home! > ... > >> I can succesfully start X-programs logging to main host such as > >> xeys, xftp, etc, but when I start netscape it says that: > >> Can't open display: :0.0 > >> Does anybody have experience on this thing? > > It hasn't ever worked. The only work-around is to specify the IP address of > the server - e.g.: > > setenv DISPLAY 198.76.54.32:0.0 Works for me. Thanks. Much nicer than the old Mosaic; I guess I should put a FreeBSD system down in the house now. Unfortunately that means braving this world of DOS/Windows/FreeBSD partitions that I've managed to avoid up til now. Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-hackers Sun Oct 15 06:05:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA24392 for hackers-outgoing; Sun, 15 Oct 1995 06:05:07 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA24378 for ; Sun, 15 Oct 1995 06:05:02 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id XAA04448; Sun, 15 Oct 1995 23:05:40 +0930 From: Michael Smith Message-Id: <199510151335.XAA04448@genesis.atrad.adelaide.edu.au> Subject: Re: Memory upgrade problems w/ 2.0.5R To: pete@dsw.com (Pete Kruckenberg) Date: Sun, 15 Oct 1995 23:05:40 +0930 (CST) Cc: hardware@freebsd.org, hackers@freefall.freebsd.org In-Reply-To: from "Pete Kruckenberg" at Oct 14, 95 12:39:31 pm Content-Type: text Content-Length: 1044 Sender: owner-hackers@freebsd.org Precedence: bulk Pete Kruckenberg stands accused of saying: > modified my conf file with 'options MEMMAX="98304"', then rebuilt the > kernel > when building the kernel, I use optimizations (gcc 2.6.3): > -O2 -m486 -fomit-frame-pointer -pipe -O2 is broken, and will result in bad code being generated. This is possibly your problem. > So, would this indicate a hardware problem, or a software problem, or > what? I'm a little hesitant to try this again until I know how to avoid > it. As soon as 2.1 comes out, I'll probably upgrade the OS, but I would > like to bump it up to 96MB now, if possible. Refrob your compile options first 8) > Pete Kruckenberg -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Sun Oct 15 06:13:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA24865 for hackers-outgoing; Sun, 15 Oct 1995 06:13:31 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA24850 for ; Sun, 15 Oct 1995 06:13:26 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id XAA04487; Sun, 15 Oct 1995 23:13:50 +0930 From: Michael Smith Message-Id: <199510151343.XAA04487@genesis.atrad.adelaide.edu.au> Subject: Re: I/O port 0 == autoconfig? - RESULTS To: bde@zeta.org.au (Bruce Evans) Date: Sun, 15 Oct 1995 23:13:50 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, uhclem%nemesis@fw.ast.com, hackers@FreeBSD.org In-Reply-To: <199510132324.JAA24147@godzilla.zeta.org.au> from "Bruce Evans" at Oct 14, 95 09:24:31 am Content-Type: text Content-Length: 992 Sender: owner-hackers@FreeBSD.org Precedence: bulk Bruce Evans stands accused of saying: > > >Speaking of the three-stage boot stuff, I'd like to hear from some/anyone > >that has a set of screen, serial and disk libraries that interact directly > >with the BIOS in the state that it's in when the bootsector is loaded. > > What's wrong with the routines in the boot loaders except they are not a > library (there is already too much duplication)? Probably nothing, only I want something I can layer a cursesalike on top of. Perhaps I should have been asking "what restrictions (size?) are there on code generated as per the second-stage bootcode?" > Bruce -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Sun Oct 15 06:19:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA25200 for hackers-outgoing; Sun, 15 Oct 1995 06:19:55 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA25192 for ; Sun, 15 Oct 1995 06:19:51 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id XAA04478; Sun, 15 Oct 1995 23:11:38 +0930 From: Michael Smith Message-Id: <199510151341.XAA04478@genesis.atrad.adelaide.edu.au> Subject: Re: I/O port 0 == autoconfig? - RESULTS To: bde@zeta.org.au (Bruce Evans) Date: Sun, 15 Oct 1995 23:11:38 +0930 (CST) Cc: joerg_wunsch@uriah.heep.sax.de, msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.org In-Reply-To: <199510132200.IAA21348@godzilla.zeta.org.au> from "Bruce Evans" at Oct 14, 95 08:00:14 am Content-Type: text Content-Length: 1018 Sender: owner-hackers@FreeBSD.org Precedence: bulk Bruce Evans stands accused of saying: > >> The visual config should translate the negative numbers into something > >> better understandable ("N/A", and "AUTO", the user can hit "a" to say > >> AUTO). > > >Ah well, so much for code reuse 8) Not a bad idea, though. > > I don't see where the lex scanner in config is being reused :-). Standard > config syntax is "?" for auto and nothing for not applicable. Why have > yet another syntax? Because "nothing" and "?" generate the same result, come kernel-time. (-1). And offhand, "N/A" and "AUTO" beat the hell out of " " and "?" for the purposes of a visual config editor. > Bruce -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Sun Oct 15 08:16:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA27462 for hackers-outgoing; Sun, 15 Oct 1995 08:16:30 -0700 Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA27454 ; Sun, 15 Oct 1995 08:16:26 -0700 Received: from muggsy.lkg.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA30930; Sun, 15 Oct 1995 08:14:04 -0700 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA08214; Sun, 15 Oct 1995 11:14:03 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id LAA01923; Sun, 15 Oct 1995 11:23:30 GMT Message-Id: <199510151123.LAA01923@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: Julian Elischer Cc: hackers@freefall.freebsd.org Subject: Re: suggested changes to mbuf routines In-Reply-To: Your message of "Sat, 14 Oct 1995 04:19:35 MST." <199510141119.EAA05158@freefall.freebsd.org> X-Mailer: exmh version 1.5omega 10/6/94 Date: Sun, 15 Oct 1995 11:21:25 +0000 From: Matt Thomas Sender: owner-hackers@FreeBSD.org Precedence: bulk In <199510141119.EAA05158@freefall.freebsd.org> , you wrote: I find the method of doing the references as done in Digital UNIX (aka DEC OSF/1) quite clean. Basically the m_ext struct gets an queue entry added. When the extended mbuf is first allocated, the link queue entry merely points to itself (an empty queue). As more references are made, their queues get linked together. As references are removed, their queues get unlinked. To see if there is a non-zero reference count, imply see if the queue entry points to itself. /* description of external storage mapped into mbuf, valid if M_EXT set */ struct m_ext { caddr_t ext_buf; /* start of buffer */ #if __STDC__ void (*ext_free)(caddr_t, u_long, caddr_t); #else void (*ext_free)(); /* free routine if not the usual */ #endif u_int ext_size; /* size of buffer, for ext_free */ caddr_t ext_arg; /* additional ext_free argument */ struct ext_refq { /* reference list */ struct ext_refq *forw, *back; } ext_ref; }; #define MCLREFERENCED(m) \ ((m)->m_ext.ext_ref.forw != &((m)->m_ext.ext_ref)) Matt Thomas Internet: matt@lkg.dec.com 3am Software Foundry WWW URL: Westford, MA Disclaimer: Digital disavows all knowledge of this message From owner-freebsd-hackers Sun Oct 15 08:21:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA27609 for hackers-outgoing; Sun, 15 Oct 1995 08:21:05 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA27603 ; Sun, 15 Oct 1995 08:20:54 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id QAA25135; Sun, 15 Oct 1995 16:20:32 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id QAA09158; Sun, 15 Oct 1995 16:20:32 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id QAA20708; Sun, 15 Oct 1995 16:16:09 +0100 From: J Wunsch Message-Id: <199510151516.QAA20708@uriah.heep.sax.de> Subject: Re: lint To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sun, 15 Oct 1995 16:16:09 +0100 (MET) Cc: davidg@freebsd.org, dyson@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510150952.TAA13687@godzilla.zeta.org.au> from "Bruce Evans" at Oct 15, 95 07:52:54 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 335 Sender: owner-hackers@freebsd.org Precedence: bulk As Bruce Evans wrote: > > lodef.h seems to be a misspelling. Yup. I couldn't read my own scribbling on the scratch sheet on my desk. :-) Should have been . -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Oct 15 09:00:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA29909 for hackers-outgoing; Sun, 15 Oct 1995 09:00:02 -0700 Received: from rover.village.org (rover.village.org [198.137.146.49]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA29874 for ; Sun, 15 Oct 1995 08:59:55 -0700 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id JAA07849; Sun, 15 Oct 1995 09:58:54 -0600 Message-Id: <199510151558.JAA07849@rover.village.org> To: "Gasparovski / Daniel (ISE)" Subject: Re: IPX now available Cc: hackers@freebsd.org In-reply-to: Your message of Sun, 15 Oct 1995 17:09:22 +1000 Date: Sun, 15 Oct 1995 09:58:54 -0600 From: Warner Losh Sender: owner-hackers@freebsd.org Precedence: bulk : Why can't this be done in the shell? It could, but pty's are "rare" on most systems (rarely than pipes at least). : eg: have the shell fork off the process, give it a pty as controlling : terminal which will be handled by the shell, and by default show it's : output on the user's tty. Then, if a "bg >& make.out" is given, have the : shell open make.out and start writing the output there instead of the tty. : : It's not the most ideal solution, for example "ls" won't do the right : thing, but it's good enough for most, if not all, situations. Since ls would be connected to a pty, it would produce the right output, no? I like this idea, but can't deside if it is too gross or not... Warner From owner-freebsd-hackers Sun Oct 15 09:00:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA29974 for hackers-outgoing; Sun, 15 Oct 1995 09:00:50 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA29958 for ; Sun, 15 Oct 1995 09:00:37 -0700 Received: by sequent.kiae.su id AA05826 (5.65.kiae-2 ); Sun, 15 Oct 1995 19:52:35 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Sun, 15 Oct 95 19:52:34 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id SAA00655; Sun, 15 Oct 1995 18:45:39 +0300 To: hackers@freefall.FreeBSD.org, "Kaleb S. KEITHLEY" References: <199510151053.GAA03600@exalt.x.org> In-Reply-To: <199510151053.GAA03600@exalt.x.org>; from "Kaleb S. KEITHLEY" at Sun, 15 Oct 1995 06:53:52 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Sun, 15 Oct 1995 18:45:39 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 39 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1645 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510151053.GAA03600@exalt.x.org> Kaleb S. KEITHLEY writes: >If I create a file that has extended ASCII (ISO8859-1) characters in the >name, ls always substitues a '?' for the non-ASCII characters. Note >that ls on, e.g. SVR4, does not do this Did you setenv ENABLE_STARTUP_LOCALE before calling ls? See environ(7) (-current). >So I think the test isprint in ls really ought to be isgraph instead. But It is a question. The only difference is space: isprint allows it and isgraph not. Does allowing spaces in file names considered bad? >just fixing ls isn't enough. The default table of character types in >libc/locale/table.c isn't populated well enought to handle the whole >ISO8859-1 character set. The following patch fixes ls, libc, and also Default code table is ASCII and _not_ ISO8859-1, so it not needed to be populated. Default code table is strict 7bit. >fixes some bugs in mklocale's lt_LN LC_CTYPE template. BLANK fixes are incorrect, see isblank(3). XDIGIT fixes are right but ASCII locale used for digits and xdigits in any cases. Other fixes which includes some additional big/lower letters probably can go, I need to check 8859-1 description first. BTW, xterm is known to dump core when any of 8bit locales set, f.e. ISO8859-1 or KOI8-R. color_xterm or mxterm works right. Can you track this bug, please? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 09:26:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA00978 for hackers-outgoing; Sun, 15 Oct 1995 09:26:47 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA00973 for ; Sun, 15 Oct 1995 09:26:41 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id RAA26341; Sun, 15 Oct 1995 17:26:33 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id RAA09523; Sun, 15 Oct 1995 17:26:33 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id RAA21043; Sun, 15 Oct 1995 17:25:57 +0100 From: J Wunsch Message-Id: <199510151625.RAA21043@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Sun, 15 Oct 1995 17:25:56 +0100 (MET) Cc: hackers@freefall.freebsd.org, kaleb@x.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 15, 95 06:45:39 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 772 Sender: owner-hackers@FreeBSD.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > >If I create a file that has extended ASCII (ISO8859-1) characters in the > >name, ls always substitues a '?' for the non-ASCII characters. Note > >that ls on, e.g. SVR4, does not do this > > Did you setenv ENABLE_STARTUP_LOCALE before calling ls? > See environ(7) (-current). IMHO, the base utilities that use should properly initialize the locale instead of relying on that hack. (The hack is useful to force programs that don't like to handle locale's, but base utilities of the system are expected to do it right theirselves.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Oct 15 09:41:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA01371 for hackers-outgoing; Sun, 15 Oct 1995 09:41:16 -0700 Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA01365 for ; Sun, 15 Oct 1995 09:41:13 -0700 Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA12916; Sun, 15 Oct 1995 09:39:26 -0700 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA08366; Sun, 15 Oct 1995 12:39:24 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id MAA02291; Sun, 15 Oct 1995 12:48:48 GMT Message-Id: <199510151248.MAA02291@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: se@zpr.uni-koeln.de (Stefan Esser) Cc: hackers@freebsd.org Subject: Re: IPX now available In-Reply-To: Your message of "Sat, 14 Oct 1995 01:20:37 +0100." <199510140020.AA18009@Sysiphos> X-Mailer: exmh version 1.5omega 10/6/94 Date: Sun, 15 Oct 1995 12:48:47 +0000 From: Matt Thomas Sender: owner-hackers@freebsd.org Precedence: bulk In <199510140020.AA18009@Sysiphos> , you wrote: > On Oct 13, 18:16, Matt Thomas wrote: > } Subject: Re: IPX now available > > } For PCI, I'm beginning in favor of having the driver call a pci_match > } routine to find instances of itself instead of the currently "passive" > } method. The passive method just doesn't lend itself to LKM. One other > > Hmm, I don't quite understand the advantage of the driver doing a "match" > in the context of LKMs ... It's more of a reversal of functions. In a static kernel where everything is known up-front, call the PCI configuration call the devices makes significant sense. However, when the world is dynamic the autoconfig code now becomes passive and the LKMs are the active components. Indeed, one very real way to look at this would be to use the DATA_SET capabilities that currently exist to store a vector of configuration/ initialization entries. So when the kernel is linked, all the initializers for devices, file systems, protocols, etc. are present in this data set. The system will define a set of synchronization points and ordering points within each sync point. So when the kernel initializes, it sorts these configuration entries and calls them one by one in order. This results in a number of benifits. The first is that the exact same modules can be used for both static-linked kernel and dynamically loaded kernel. Another benifit is that you can develop and debug almost all the mechanisms needed for a truly dynamic kernel using the existing static kernel framework. [For the kernel described above, it might be useful if ld supported a new MAGIC type image. Such that whenever a new module is loaded, its code and data and bss are contiguous and never overlap with another module. This would allow the memory used by a module to be recovered if it determined that it is not needed.] -- In this instance, let's say the PCI support LKM get loaded, it walks the PCI bus/device tree and sets up it's data structures. Then it returns back to the kernel initializer. Now comes a PCI device, it calls pci_match to find the first unassigned device that matches its earch criterea. device_cookie = NULL; while (device_cookie = pci_devmatch(device_cookie, my_match_function)) != NULL) pci_devattach(device_cookie, my_attach_function); Indeed, there could be a convenience routine that does the above. pci_devconfigure(my_match_function, my_attach_function); It's implicit is that all drivers be all to configure any number of devices. > PCI device LKMs ought to be named according to their vendor and device IDs. > E.g. the NCR driver might be looked up under "/lkm/pci_v1000d0001.o" which > is a link to /lkm/ncr_scsi.o" or the DEC 21040 under "/lkm/pci_v1011d0002.o" > which might be a link to "/lkm/if_de.o" ... I strongly disagree. In my view, a LKM controls its own fate. The kernel (or other LKMs on which this LKM depends) merely provided services which it can use. Indeed, as far as the system is concerned there should be no difference between a FS LKM or a device LKM or protocol LKM or a syscall LKM. Once the LKM's configuration entry point has been called, the LKM is in control. > } reason I favor it is so that I could have a "generic" DC21x4X module > } and then have various board/chip specific LKMs. The de driver is getting > } fairly large and I'd like a method to trim out the unneeded code. > > PCI 2.1 extends the vendor and device ID concept. It is now possible to > have a board vendor/device ID independent from the chip's ID. True, the subsystem ID will be useful but that doesn't help with all the current devices which don't have that. > This opens a generic way to load a board specific driver, instead of only > a chip specific one ... For those boards that will support it... Matt Thomas Internet: matt@lkg.dec.com 3am Software Foundry WWW URL: Westford, MA Disclaimer: Digital disavows all knowledge of this message From owner-freebsd-hackers Sun Oct 15 10:16:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA02587 for hackers-outgoing; Sun, 15 Oct 1995 10:16:07 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA02580 for ; Sun, 15 Oct 1995 10:15:48 -0700 Received: by sequent.kiae.su id AA17766 (5.65.kiae-2 ); Sun, 15 Oct 1995 21:06:00 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Sun, 15 Oct 95 21:06:00 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id UAA01196; Sun, 15 Oct 1995 20:05:15 +0300 To: hackers@freefall.FreeBSD.org, "Kaleb S. KEITHLEY" References: <199510151053.GAA03600@exalt.x.org> In-Reply-To: ; from =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= at Sun, 15 Oct 1995 18:45:39 +0300 (MSK) Message-Id: Organization: Olahm Ha-Yetzirah Date: Sun, 15 Oct 1995 20:05:14 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 13 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 579 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= writes: >Other fixes which includes some additional big/lower letters probably >can go, I need to check 8859-1 description first. FYI, I just commit some of your fixes into -current. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 10:17:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA02698 for hackers-outgoing; Sun, 15 Oct 1995 10:17:41 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA02653 for ; Sun, 15 Oct 1995 10:17:12 -0700 Received: by sequent.kiae.su id AA17762 (5.65.kiae-2 ); Sun, 15 Oct 1995 21:05:57 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Sun, 15 Oct 95 21:05:56 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id UAA01169; Sun, 15 Oct 1995 20:02:26 +0300 To: Joerg Wunsch Cc: hackers@freefall.freebsd.org, kaleb@x.org References: <199510151625.RAA21043@uriah.heep.sax.de> In-Reply-To: <199510151625.RAA21043@uriah.heep.sax.de>; from J Wunsch at Sun, 15 Oct 1995 17:25:56 +0100 (MET) Message-Id: Organization: Olahm Ha-Yetzirah Date: Sun, 15 Oct 1995 20:02:26 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 25 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1102 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510151625.RAA21043@uriah.heep.sax.de> J Wunsch writes: >As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: >> >> >If I create a file that has extended ASCII (ISO8859-1) characters in the >> >name, ls always substitues a '?' for the non-ASCII characters. Note >> >that ls on, e.g. SVR4, does not do this >> >> Did you setenv ENABLE_STARTUP_LOCALE before calling ls? >> See environ(7) (-current). >IMHO, the base utilities that use should properly initialize >the locale instead of relying on that hack. (The hack is useful to >force programs that don't like to handle locale's, but base utilities >of the system are expected to do it right theirselves.) You need different crt0 for native FreeBSD utilities and any other which you can compile, i.e. ports collection. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 10:30:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA03077 for hackers-outgoing; Sun, 15 Oct 1995 10:30:51 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA03072 for ; Sun, 15 Oct 1995 10:30:39 -0700 Received: by sequent.kiae.su id AA21387 (5.65.kiae-2 ); Sun, 15 Oct 1995 21:26:28 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Sun, 15 Oct 95 21:26:28 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id UAA01328; Sun, 15 Oct 1995 20:25:07 +0300 To: Joerg Wunsch Cc: hackers@freefall.freebsd.org, kaleb@x.org References: <199510151625.RAA21043@uriah.heep.sax.de> In-Reply-To: <199510151625.RAA21043@uriah.heep.sax.de>; from J Wunsch at Sun, 15 Oct 1995 17:25:56 +0100 (MET) Message-Id: Organization: Olahm Ha-Yetzirah Date: Sun, 15 Oct 1995 20:25:07 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 26 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1205 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510151625.RAA21043@uriah.heep.sax.de> J Wunsch writes: >As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: >> >> >If I create a file that has extended ASCII (ISO8859-1) characters in the >> >name, ls always substitues a '?' for the non-ASCII characters. Note >> >that ls on, e.g. SVR4, does not do this >> >> Did you setenv ENABLE_STARTUP_LOCALE before calling ls? >> See environ(7) (-current). >IMHO, the base utilities that use should properly initialize >the locale instead of relying on that hack. (The hack is useful to >force programs that don't like to handle locale's, but base utilities >of the system are expected to do it right theirselves.) I have nothing against reverting this variable to DISABLE_STARTUP_LOCALE f.e. If you remember I plan to make startup locale as default for all program, but some peoples disagree, so I introduce ENABLE_STARTUP_LOCALE. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 10:48:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA04568 for hackers-outgoing; Sun, 15 Oct 1995 10:48:51 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA04563 for ; Sun, 15 Oct 1995 10:48:49 -0700 Received: from exalt.x.org by expo.x.org id AA10230; Sun, 15 Oct 95 13:48:00 -0400 Received: from localhost by exalt.x.org id NAA04827; Sun, 15 Oct 1995 13:47:59 -0400 Message-Id: <199510151747.NAA04827@exalt.x.org> To: hackers@freefall.FreeBSD.org Cc: ache@astral.msk.su Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Sun, 15 Oct 1995 17:25:56 EST. <199510151625.RAA21043@uriah.heep.sax.de> Organization: X Consortium Date: Sun, 15 Oct 1995 13:47:59 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk Andrey Chernov said: >>just fixing ls isn't enough. The default table of character types in >>libc/locale/table.c isn't populated well enought to handle the whole >>ISO8859-1 character set. The following patch fixes ls, libc, and also >Default code table is ASCII and _not_ ISO8859-1, so it not needed to be >populated. Default code table is strict 7bit. No, it doesn't need to be, but is there a reason it can't do the right thing anyway? The table is defined as having 256 elements, so populating it with something useful isn't going to hurt anything. >>fixes some bugs in mklocale's lt_LN LC_CTYPE template. >BLANK fixes are incorrect, see isblank(3). Then the man page is wrong. The interpretation of blank on e.g. SVR4 is that *only* '0x20' is a "blank". On at least one SVR4 system I have here this is documented as specified by ISO8859-1. Compatibility is a good thing. I think you should be compatible. >XDIGIT fixes are right but ASCII locale used >for digits and xdigits in any cases. I'm not sure what this means. >Other fixes which includes some additional big/lower letters probably >can go, I need to check 8859-1 description first. You can check if you want. :-) >BTW, xterm is known to dump core when any of 8bit locales set, >f.e. ISO8859-1 or KOI8-R. color_xterm or mxterm works right. >Can you track this bug, please? What bug would this be? I'm not having any trouble at all running xterm in ISO8859-1 locales on FreeBSD 2.1.0-950922-SNAP (and I wouldn't have the first idea what to do in the KOI8-R locale :-)). You aren't by any chance using XFree86's xterm are you? If so report the problem to them. -- Kaleb KEITHLEY X Consortium From owner-freebsd-hackers Sun Oct 15 11:06:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA04863 for hackers-outgoing; Sun, 15 Oct 1995 11:06:15 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA04858 for ; Sun, 15 Oct 1995 11:06:13 -0700 Received: from exalt.x.org by expo.x.org id AA10326; Sun, 15 Oct 95 14:05:27 -0400 Received: from localhost by exalt.x.org id OAA04841; Sun, 15 Oct 1995 14:05:21 -0400 Message-Id: <199510151805.OAA04841@exalt.x.org> To: hackers@freefall.FreeBSD.org Cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Sun, 15 Oct 1995 17:25:56 EST. <199510151625.RAA21043@uriah.heep.sax.de> Organization: X Consortium Date: Sun, 15 Oct 1995 14:05:21 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > > > >If I create a file that has extended ASCII (ISO8859-1) characters in the > > >name, ls always substitues a '?' for the non-ASCII characters. Note > > >that ls on, e.g. SVR4, does not do this > > > > Did you setenv ENABLE_STARTUP_LOCALE before calling ls? > > See environ(7) (-current). > > IMHO, the base utilities that use should properly initialize > the locale instead of relying on that hack. (The hack is useful to > force programs that don't like to handle locale's, but base utilities > of the system are expected to do it right theirselves.) Yup, they could. It'd be a lot of work to go through every program and add it. I could be way off base (great U.S./American colloquillism) but my guess is that most programs probably don't need it unless you're also going to make them use message catalogs at the same time, adding even more work and probably compounding the issue of having a single boot floppy and or loading in 4Meg. As near as I can tell the SVR4 ls doesn't change its locale, yet still manages to do the right thing, probably because for most SVR4-en the C locale is full ISO8859-1. This leads me to believe that FreeBSD's ls probably doesn't need to change its locale either if the default chartype table is fully populated. -- Kaleb From owner-freebsd-hackers Sun Oct 15 12:06:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA05824 for hackers-outgoing; Sun, 15 Oct 1995 12:06:39 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA05819 for ; Sun, 15 Oct 1995 12:06:35 -0700 Received: from exalt.x.org by expo.x.org id AA10661; Sun, 15 Oct 95 15:05:40 -0400 Received: from localhost by exalt.x.org id PAA04897; Sun, 15 Oct 1995 15:05:37 -0400 Message-Id: <199510151905.PAA04897@exalt.x.org> To: hackers@freefall.FreeBSD.org Cc: ache@astral.msk.su Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Sun, 15 Oct 1995 18:45:39 EST. Organization: X Consortium Date: Sun, 15 Oct 1995 15:05:37 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > In message <199510151053.GAA03600@exalt.x.org> Kaleb S. KEITHLEY > writes: > > >If I create a file that has extended ASCII (ISO8859-1) characters in the > >name, ls always substitues a '?' for the non-ASCII characters. Note > >that ls on, e.g. SVR4, does not do this > > Did you setenv ENABLE_STARTUP_LOCALE before calling ls? > See environ(7) (-current). For the most part stuff in -current might as well not exist as far as I'm concerned. The X Consortium only supports released versions of any particular OS, and then it officially only supports that same version over the life of that particular release of X11. I'm already stretching things as far as I can by running SNAP releases, and that's only because I have faith that 2.1 will be real before our next release. (Not much of a stretch really, our next release is months away.) That notwithstanding, I agree with Joerg, it's a hack and users shouldn't have to resort to hacks to have things work correctly or reasonably, or even reasonably correctly. (I have taken /bin/sh from -current. I hope you won't let me down by not having that in the GA release of 2.1.0. Note also that the X Consortium does add support for later OS versions in the public patches, but they're just not *officially* supported.) > >So I think the test isprint in ls really ought to be isgraph instead. > > It is a question. The only difference is space: isprint allows it and isgraph > not. Does allowing spaces in file names considered bad? > In a separate context you cited the man page (and I think the man page is wrong in that case.) Now I'm going to do the same thing. :-) The FreeBSD man page for ls says that '?' is substituted for non-*graphical* characters (and the SVR4 man page is in agreement. I wonder what POSIX says?) Since a space is not a graphical character, whether you think printing spaces is good or bad it's pretty clear that a space must have a '?' substituted in its place when -q is in effect. If the only difference is a space then I think you should make the change. -- Kaleb From owner-freebsd-hackers Sun Oct 15 12:19:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA05998 for hackers-outgoing; Sun, 15 Oct 1995 12:19:48 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA05993 for ; Sun, 15 Oct 1995 12:19:21 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id VAA22709 for ; Sun, 15 Oct 1995 21:19:04 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id VAA23932 for ; Sun, 15 Oct 1995 21:19:03 +0200 Message-Id: <199510151919.VAA23932@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: hackers@freebsd.org Subject: Creating a /dev/random Date: Sun, 15 Oct 1995 21:19:03 +0200 From: Mark Murray Sender: owner-hackers@freebsd.org Precedence: bulk Hi I am slowly hacking my way through the kernel, figuring out how to do things. So far, I am doing OK, but with lots of help. Thanks guys! I am building devices, /dev/random and /dev/urandom that when read give random noise generated in and by the kernel. So far it is going pretty well, but I have some unexplained hangs. I believe these are due to my complete lack of knowledge of what the uiomove() function is supposed to do. Please have a look at my mods to mem.c (the home of /dev/null) and make some suggestions: Notes: 1) read_random() only returns the number of random bytes it thinks are truly random, and should cause /dev/random to return EOF when this "pool of entropy" is empty. 2) it is this /dev/random that dies. If I continually open/read/close the kernel will wedge. No reboot, syscons is alive, but everything else stops. 3) read_random_unlimited always returns the number of bytes requested, even if they are dubious. This is central to /dev/urandom, which I tried to model on /dev/zero (except for the return value :-]) 4) /dev/urandom never seems to kill the system. 5) the kernel is 'hooked' to provide a contunual source of randomness. (interrupts, keystrokes etc) diff --exclude=CVS -udr sys.ORG/i386/i386/mem.c sys/i386/i386/mem.c --- sys.ORG/i386/i386/mem.c Wed Sep 20 15:01:17 1995 +++ sys/i386/i386/mem.c Mon Oct 2 22:59:44 1995 @@ -135,6 +139,10 @@ register struct iovec *iov; int error = 0; caddr_t zbuf = NULL; +#ifdef DEVRANDOM + caddr_t rbuf = NULL; + int poolsize; +#endif while (uio->uio_resid > 0 && error == 0) { iov = uio->uio_iov; @@ -190,6 +198,40 @@ return (0); c = iov->iov_len; break; + +#ifdef DEVRANDOM +/* minor device 3 is filth generator /dev/random - rathole on write */ + case 3: + if (uio->uio_rw == UIO_WRITE) { + c = iov->iov_len; + break; + } + if (rbuf == NULL) { + rbuf = (caddr_t) + malloc(CLBYTES, M_TEMP, M_WAITOK); + } + poolsize = read_random(rbuf, CLBYTES); + c = min(iov->iov_len, CLBYTES); + c = min(c, poolsize); + error = uiomove(rbuf, (int)c, uio); + continue; + +/* minor device 4 is dirt generator /dev/urandom - rathole on write */ + case 4: + if (uio->uio_rw == UIO_WRITE) { + c = iov->iov_len; + break; + } + if (rbuf == NULL) { + rbuf = (caddr_t) + malloc(CLBYTES, M_TEMP, M_WAITOK); + } + poolsize = read_random_unlimited(rbuf, CLBYTES); + c = min(iov->iov_len, CLBYTES); + c = min(c, poolsize); + error = uiomove(rbuf, (int)c, uio); + continue; +#endif /* minor device 12 (/dev/zero) is source of nulls on read, rathole on write */ case 12: -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-hackers Sun Oct 15 12:27:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA06184 for hackers-outgoing; Sun, 15 Oct 1995 12:27:42 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA06176 for ; Sun, 15 Oct 1995 12:27:36 -0700 Received: by Sysiphos id AA27823 (5.67b/IDA-1.5 for hackers@freefall.freebsd.org); Sun, 15 Oct 1995 20:23:45 +0100 Message-Id: <199510151923.AA27823@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Sun, 15 Oct 1995 20:23:44 +0100 In-Reply-To: Pete Kruckenberg "Memory upgrade problems w/ 2.0.5R" (Oct 14, 12:39) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Pete Kruckenberg Subject: Re: Memory upgrade problems w/ 2.0.5R Cc: hardware@freebsd.org, hackers@freefall.freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk On Oct 14, 12:39, Pete Kruckenberg wrote: } Subject: Memory upgrade problems w/ 2.0.5R } Last night, I attempted to upgrade my FreeBSD 2.0.5R news/Web server from } 64 to 96MB. It ended in slight disaster. I wanted to find out if I missed } something critical, or if one or both of my SIMMs might have been bad. } } Here's what I did: } } modified my conf file with 'options MEMMAX="98304"', then rebuilt the } kernel } when building the kernel, I use optimizations (gcc 2.6.3): } -O2 -m486 -fomit-frame-pointer -pipe Hmm, is "-fomit-frame-pointer" legal when compiling the kernel ??? Maybe something depends on the stack always being in "standard" format ? -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-hackers Sun Oct 15 12:28:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA06216 for hackers-outgoing; Sun, 15 Oct 1995 12:28:59 -0700 Received: from frig.mt.cs.keio.ac.jp (frig.mt.cs.keio.ac.jp [131.113.32.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA06211 for ; Sun, 15 Oct 1995 12:28:56 -0700 Received: (from hosokawa@localhost) by frig.mt.cs.keio.ac.jp (8.6.12+2.4W/3.4Wbeta3) id EAA25631; Mon, 16 Oct 1995 04:23:38 +0900 Date: Mon, 16 Oct 1995 04:23:38 +0900 Message-Id: <199510151923.EAA25631@frig.mt.cs.keio.ac.jp> To: didier@aida.org Cc: hackers@freebsd.org, hosokawa@mt.cs.keio.ac.jp Subject: Re: crash while running xanim In-Reply-To: Your message of Sun, 15 Oct 1995 09:08:11 +0100 (MET). From: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) X-Mailer: mnews [version 1.18PL3] 1994-08/01(Mon) Sender: owner-hackers@freebsd.org Precedence: bulk In article didier@aida.org writes: >> My computer crashed while I was playing a large .avi file (robroy.avi >> from the Windows 95 cdrom). >> I found these messages in /var/log/messages: >> >> swap_pager: out of space >> process 302 killed by vm_fault -- out of swap. Use xanim with +f option. hosokawa From owner-freebsd-hackers Sun Oct 15 14:16:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA11600 for hackers-outgoing; Sun, 15 Oct 1995 14:16:07 -0700 Received: from elxr.jpl.nasa.gov (elxr-fddi.jpl.nasa.gov [137.78.160.8]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA11593 for ; Sun, 15 Oct 1995 14:16:02 -0700 Received: from localhost.jpl.nasa.gov (localhost.jpl.nasa.gov [127.0.0.1]) by elxr.jpl.nasa.gov (8.6.12/8.6.6) with SMTP id OAA08404; Sun, 15 Oct 1995 14:15:25 -0700 Message-Id: <199510152115.OAA08404@elxr.jpl.nasa.gov> To: Mark Murray Cc: hackers@freebsd.org Subject: Re: Creating a /dev/random Date: Sun, 15 Oct 1995 14:15:25 -0700 From: Dave Hayes Sender: owner-hackers@freebsd.org Precedence: bulk Mark Murray writes: >I am building devices, /dev/random and /dev/urandom that when read give >random noise generated in and by the kernel. How is this noise generated? Is it really random, by statistical tests? Is there any chance of having an option to take random bits from an existing sound card if there is one there? ------ Dave Hayes -- Institutional NETworks - Section 394 -- JPL/NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ...usc!elroy!dxh To the ignorant, a pearl seems a mere stone. From owner-freebsd-hackers Sun Oct 15 14:50:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA12545 for hackers-outgoing; Sun, 15 Oct 1995 14:50:55 -0700 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA12532 for ; Sun, 15 Oct 1995 14:50:52 -0700 Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA03254; Sun, 15 Oct 1995 17:50:20 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sun, 15 Oct 1995 17:50 EDT Received: from lakes (lakes [192.96.3.39]) by ponds.UUCP (8.6.11/8.6.5) with ESMTP id RAA15099; Sun, 15 Oct 1995 17:39:29 -0400 Received: (from rivers@localhost) by lakes (8.6.11/8.6.9) id RAA01382; Sun, 15 Oct 1995 17:38:27 -0400 Date: Sun, 15 Oct 1995 17:38:27 -0400 From: Thomas David Rivers Message-Id: <199510152138.RAA01382@lakes> To: starkhome.cs.sunysb.edu!gene@dg-rtp.dg.com, dg-rtp.dg.com!ponds!rivers@sbstark.cs.sunysb.edu Subject: Re: Recording from SB16 in 2.0.5? Cc: hackers@freebsd.org Content-Type: text Content-Length: 284 Sender: owner-hackers@freebsd.org Precedence: bulk > > >Has anyone been successful at recording sound with the sound-blaster-16 > >driver in 2.0.5? > > Not in 2.0.5, but in -stable it works OK with NAS, vmix, or just > catting /dev/audio. > > - Gene > Okey-Dokey - I'll wait for 2.1 and try it then. - Dave Rivers - From owner-freebsd-hackers Sun Oct 15 15:24:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA12916 for hackers-outgoing; Sun, 15 Oct 1995 15:24:45 -0700 Received: from ns.easy.re.kr ([203.241.171.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA12911 for ; Sun, 15 Oct 1995 15:24:39 -0700 Received: (from moonhunt@localhost) by ns.easy.re.kr (8.6.12H1/8.6.9) id HAA01285 for freebsd-hackers@freebsd.org; Mon, 16 Oct 1995 07:23:41 +0900 Date: Mon, 16 Oct 1995 07:23:41 +0900 From: HyunSeog Ryu Message-Id: <199510152223.HAA01285@ns.easy.re.kr> To: freebsd-hackers@freebsd.org Subject: Question about SCCS-like utilities??? Sender: owner-hackers@freebsd.org Precedence: bulk Dear anyone, Please let me know what are SCCS-like utility... I want to perform Source Code version control... ;> Thank you for your reading this message... From Hyunseog Ryu =============================================================================== Name : Hyunseog Ryu moonhunt@easy.re.kr Tel : +82-2-884-0174 http://www.easy.re.kr/~moonhunt Fax : +82-2-884-0175 :-) EASY research institute Tomorrow is another day... ;> 4th floor, 304-25, shinrim 10-dong For better world, cheers!!! Kwanak-gu, Seoul, 151-020, Korea :-D =============================================================================== From owner-freebsd-hackers Sun Oct 15 15:52:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA13333 for hackers-outgoing; Sun, 15 Oct 1995 15:52:37 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA13328 for ; Sun, 15 Oct 1995 15:52:34 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id IAA32542; Mon, 16 Oct 1995 08:52:00 +1000 Date: Mon, 16 Oct 1995 08:52:00 +1000 From: Bruce Evans Message-Id: <199510152252.IAA32542@godzilla.zeta.org.au> To: ache@astral.msk.su, j@uriah.heep.sax.de Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Cc: hackers@freefall.freebsd.org, kaleb@x.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >> Did you setenv ENABLE_STARTUP_LOCALE before calling ls? >> See environ(7) (-current). >IMHO, the base utilities that use should properly initialize >the locale instead of relying on that hack. (The hack is useful to >force programs that don't like to handle locale's, but base utilities >of the system are expected to do it right theirselves.) BTW, this hack adds 24K to the size of a minimal statically linked program `main() {}' and defeats the point of most of the specially named routines in crt0.c. E.g., there is a special version of getenv() named _getenv() to avoid the namespace pollution and bloat from getenv(), but the hack calls getenv() anyway; there are special versions of read() and write(), but _startup_setlocale() references things in stdio that reference read() and write(). atexit() support adds another 28K. Less for real programs of course. The bloat is really in libc, where almost everything references too many other things. Bruce echo 'main() {}' >z0.c echo 'main() {} getenv() {} _startup_setlocale() {}' >z1.c echo 'main() {} getenv() {} _startup_setlocale() {} atexit() {}' >z2.c for i in 0 1 2; do cc -O -o z$i z$i.c -static -s; done ls -l z0 z1 z2 From owner-freebsd-hackers Sun Oct 15 16:00:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA13478 for hackers-outgoing; Sun, 15 Oct 1995 16:00:31 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA13470 for ; Sun, 15 Oct 1995 16:00:23 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA03744 for ; Mon, 16 Oct 1995 00:00:02 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id AAA12881 for hackers@freefall.freebsd.org; Mon, 16 Oct 1995 00:00:02 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id XAA22059 for hackers@freefall.freebsd.org; Sun, 15 Oct 1995 23:56:50 +0100 From: J Wunsch Message-Id: <199510152256.XAA22059@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: hackers@freefall.freebsd.org Date: Sun, 15 Oct 1995 23:56:49 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 15, 95 08:02:26 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 598 Sender: owner-hackers@FreeBSD.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > >IMHO, the base utilities that use should properly initialize > >the locale instead of relying on that hack. > > You need different crt0 for native FreeBSD utilities and any other > which you can compile, i.e. ports collection. You misunderstood me. I was thinking of an explicit setlocale() inside all system utilities (except daemons) that use . -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Oct 15 16:06:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA13629 for hackers-outgoing; Sun, 15 Oct 1995 16:06:28 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA13623 for ; Sun, 15 Oct 1995 16:06:24 -0700 Received: by Sysiphos id AA28894 (5.67b/IDA-1.5 for hackers@freebsd.org); Mon, 16 Oct 1995 00:05:11 +0100 Message-Id: <199510152305.AA28894@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 16 Oct 1995 00:05:11 +0100 In-Reply-To: HyunSeog Ryu "Question about SCCS-like utilities???" (Oct 16, 7:23) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: HyunSeog Ryu Subject: Re: Question about SCCS-like utilities??? Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk On Oct 16, 7:23, HyunSeog Ryu wrote: } Subject: Question about SCCS-like utilities??? } Dear anyone, } } Please let me know what are SCCS-like utility... } I want to perform Source Code version control... ;> SCCS is a System V thing, and AFAIK not available for free ... The BSD equivalent is RCS, and there is an enhanced version for larger projects called CVS. Both are now distributed under a GNU Copyright and come with FreeBSD. These are the tools used to make some 50 people integrate their code into the FreeBSD source tree, without stepping on each others toes to often :) Reading the man pages of "rcs" and "cvs" should get you going. There are "troff" sources of a RCS users manual in /usr/src/gnu/usr.bin/rcs/doc/rcs.ms and "texinfo" sources of a CVS manual in /usr/src/gnu/usr.bin/cvs/doc/cvs.texinfo Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-hackers Sun Oct 15 16:07:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA13659 for hackers-outgoing; Sun, 15 Oct 1995 16:07:04 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA13651 for ; Sun, 15 Oct 1995 16:06:57 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA03847 for ; Mon, 16 Oct 1995 00:06:49 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id AAA12930 for freebsd-hackers@freebsd.org; Mon, 16 Oct 1995 00:06:48 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id XAA22206 for freebsd-hackers@freebsd.org; Sun, 15 Oct 1995 23:59:43 +0100 From: J Wunsch Message-Id: <199510152259.XAA22206@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sun, 15 Oct 1995 23:59:43 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 15, 95 08:25:07 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 761 Sender: owner-hackers@freebsd.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > I have nothing against reverting this variable to > DISABLE_STARTUP_LOCALE f.e. If you remember I plan to make startup locale > as default for all program, but some peoples disagree, so I introduce > ENABLE_STARTUP_LOCALE. The ENABLE_STARTUP_LOCALE hack is nice for those programs that are not even aware of locale's. The base utilities however should be aware if it, and handle it themselves. As i said in another message, except perhaps daemons. All other utilities that use the isctype()-style macros/functions should use it. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Oct 15 16:07:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA13679 for hackers-outgoing; Sun, 15 Oct 1995 16:07:09 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA13658 for ; Sun, 15 Oct 1995 16:07:03 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA03851; Mon, 16 Oct 1995 00:06:50 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id AAA12931; Mon, 16 Oct 1995 00:06:50 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id AAA22305; Mon, 16 Oct 1995 00:03:59 +0100 From: J Wunsch Message-Id: <199510152303.AAA22305@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Mon, 16 Oct 1995 00:03:59 +0100 (MET) Cc: hackers@freefall.freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510151805.OAA04841@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 15, 95 02:05:21 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 826 Sender: owner-hackers@FreeBSD.org Precedence: bulk As Kaleb S. KEITHLEY wrote: > > As near as I can tell the SVR4 ls doesn't change its locale, yet still > manages to do the right thing, probably because for most SVR4-en the C > locale is full ISO8859-1. This leads me to believe that FreeBSD's ls > probably doesn't need to change its locale either if the default chartype > table is fully populated. So SVR4 would still break on koi8-r, for example. Either make it right, or let it be. isctype() is not necessarily related to message catalogs. The extensive (i.e. blatant) use of message catalogs (AIX, IRIX) leads to very undesirable results, e.g. SMTP daemons throwing their error messages in German. :-( -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Oct 15 16:11:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA13962 for hackers-outgoing; Sun, 15 Oct 1995 16:11:53 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA13957 for ; Sun, 15 Oct 1995 16:11:51 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id QAA06034; Sun, 15 Oct 1995 16:11:33 -0700 Message-Id: <199510152311.QAA06034@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Thomas David Rivers cc: starkhome.cs.sunysb.edu!gene@dg-rtp.dg.com, dg-rtp.dg.com!ponds!rivers@sbstark.cs.sunysb.edu, hackers@freebsd.org Subject: Re: Recording from SB16 in 2.0.5? In-reply-to: Your message of "Sun, 15 Oct 1995 17:38:27 EDT." <199510152138.RAA01382@lakes> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 15 Oct 1995 16:11:33 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk >>> Thomas David Rivers said: > > > > >Has anyone been successful at recording sound with the sound-blaster-16 > > >driver in 2.0.5? > > > > Not in 2.0.5, but in -stable it works OK with NAS, vmix, or just > > catting /dev/audio. > > > > - Gene > > > > Okey-Dokey - > > I'll wait for 2.1 and try it then. > Or, you can grab the sound driver from -stable and try it. tar -cf sound.tar --stable-/sys/i386/isa/sound then on your system , cd /sys/i386/isa mv sound sound.old tar -xf sound.tar rebuild the kernel and off you go ... Amancio From owner-freebsd-hackers Sun Oct 15 16:12:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA13995 for hackers-outgoing; Sun, 15 Oct 1995 16:12:55 -0700 Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA13983 for ; Sun, 15 Oct 1995 16:12:17 -0700 Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.11/8.6.11) with SMTP id AAA28568 ; Mon, 16 Oct 1995 00:05:04 +0100 To: HyunSeog Ryu cc: freebsd-hackers@freebsd.org Subject: Re: Question about SCCS-like utilities??? In-reply-to: Your message of "Mon, 16 Oct 1995 07:23:41 +0900." <199510152223.HAA01285@ns.easy.re.kr> Date: Mon, 16 Oct 1995 00:05:01 +0100 Message-ID: <28566.813798301@palmer.demon.co.uk> From: Gary Palmer Sender: owner-hackers@freebsd.org Precedence: bulk >Please let me know what are SCCS-like utility... >I want to perform Source Code version control... ;> RCS is supplied with FreeBSD, along with CVS (Concurrent Version System). CVS is what we use on freefall for maintaining the master FreeBSD source repository and revision control... Gary From owner-freebsd-hackers Sun Oct 15 16:14:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA14054 for hackers-outgoing; Sun, 15 Oct 1995 16:14:07 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA14046 for ; Sun, 15 Oct 1995 16:14:04 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA03958; Mon, 16 Oct 1995 00:14:00 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id AAA12974; Mon, 16 Oct 1995 00:14:00 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id AAA22385; Mon, 16 Oct 1995 00:09:09 +0100 From: J Wunsch Message-Id: <199510152309.AAA22385@uriah.heep.sax.de> Subject: Re: Memory upgrade problems w/ 2.0.5R To: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 16 Oct 1995 00:09:08 +0100 (MET) Cc: pete@dsw.com, hardware@freebsd.org, hackers@freefall.freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510151923.AA27823@Sysiphos> from "Stefan Esser" at Oct 15, 95 08:23:44 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 551 Sender: owner-hackers@freebsd.org Precedence: bulk As Stefan Esser wrote: > > } -O2 -m486 -fomit-frame-pointer -pipe > > Hmm, is "-fomit-frame-pointer" legal > when compiling the kernel ??? > > Maybe something depends on the stack > always being in "standard" format ? AFAIK, only DDB. omit-frame-pointer is IMHO a rather useless hack. It doesn't gain that much, and causes only trouble in case of some error to track. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Oct 15 16:14:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA14073 for hackers-outgoing; Sun, 15 Oct 1995 16:14:09 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA14048 for ; Sun, 15 Oct 1995 16:14:06 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA03962; Mon, 16 Oct 1995 00:14:02 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id AAA12975; Mon, 16 Oct 1995 00:14:02 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id AAA22404; Mon, 16 Oct 1995 00:11:12 +0100 From: J Wunsch Message-Id: <199510152311.AAA22404@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Mon, 16 Oct 1995 00:11:12 +0100 (MET) Cc: hackers@freefall.freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510151905.PAA04897@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 15, 95 03:05:37 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 625 Sender: owner-hackers@FreeBSD.org Precedence: bulk As Kaleb S. KEITHLEY wrote: > > (I have taken /bin/sh from -current. I hope you won't let me down by not > having that in the GA release of 2.1.0. Note also that the X Consortium > does add support for later OS versions in the public patches, but they're > just not *officially* supported.) AFAIK, all of the bug fixes and bug fix fixes (or must it be "bug bug fixes"? :-) for -current /bin/sh are in the 2.1 branch, too. There are still more things to fix. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Oct 15 16:14:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA14112 for hackers-outgoing; Sun, 15 Oct 1995 16:14:23 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA14107 for ; Sun, 15 Oct 1995 16:14:18 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA03970; Mon, 16 Oct 1995 00:14:05 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id AAA12979; Mon, 16 Oct 1995 00:14:05 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id AAA22439; Mon, 16 Oct 1995 00:13:05 +0100 From: J Wunsch Message-Id: <199510152313.AAA22439@uriah.heep.sax.de> Subject: Re: Question about SCCS-like utilities??? To: moonhunt@easy.re.kr (HyunSeog Ryu) Date: Mon, 16 Oct 1995 00:13:04 +0100 (MET) Cc: freebsd-hackers@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510152223.HAA01285@ns.easy.re.kr> from "HyunSeog Ryu" at Oct 16, 95 07:23:41 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 400 Sender: owner-hackers@freebsd.org Precedence: bulk As HyunSeog Ryu wrote: > Please let me know what are SCCS-like utility... > I want to perform Source Code version control... ;> SCCS would require an AT&T or WE or Novel or SCO or ... license. Are you dissatisfied with RCS and/or CVS? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Oct 15 16:15:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA14229 for hackers-outgoing; Sun, 15 Oct 1995 16:15:54 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA14220 for ; Sun, 15 Oct 1995 16:15:51 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA04016; Mon, 16 Oct 1995 00:15:48 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id AAA12997; Mon, 16 Oct 1995 00:15:48 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id AAA22520; Mon, 16 Oct 1995 00:15:13 +0100 From: J Wunsch Message-Id: <199510152315.AAA22520@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: bde@zeta.org.au (Bruce Evans) Date: Mon, 16 Oct 1995 00:15:12 +0100 (MET) Cc: freebsd-hackers@freebsd.org (FreeBSD hackers) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510152252.IAA32542@godzilla.zeta.org.au> from "Bruce Evans" at Oct 16, 95 08:52:00 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 426 Sender: owner-hackers@freebsd.org Precedence: bulk As Bruce Evans wrote: > > echo 'main() {}' >z0.c > echo 'main() {} getenv() {} _startup_setlocale() {}' >z1.c > echo 'main() {} getenv() {} _startup_setlocale() {} atexit() {}' >z2.c > for i in 0 1 2; do cc -O -o z$i z$i.c -static -s; done > ls -l z0 z1 z2 :-(( -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Oct 15 16:46:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA15784 for hackers-outgoing; Sun, 15 Oct 1995 16:46:03 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA15779 for ; Sun, 15 Oct 1995 16:45:57 -0700 Received: by sequent.kiae.su id AA02884 (5.65.kiae-2 ); Mon, 16 Oct 1995 03:38:58 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 03:38:58 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id CAA00551; Mon, 16 Oct 1995 02:37:17 +0300 To: hackers@freefall.FreeBSD.org, "Kaleb S. KEITHLEY" References: <199510151905.PAA04897@exalt.x.org> In-Reply-To: <199510151905.PAA04897@exalt.x.org>; from "Kaleb S. KEITHLEY" at Sun, 15 Oct 1995 15:05:37 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 02:37:17 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 53 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2412 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510151905.PAA04897@exalt.x.org> Kaleb S. KEITHLEY writes: >> In message <199510151053.GAA03600@exalt.x.org> Kaleb S. KEITHLEY >> writes: >> >> >If I create a file that has extended ASCII (ISO8859-1) characters in the >> >name, ls always substitues a '?' for the non-ASCII characters. Note >> >that ls on, e.g. SVR4, does not do this >> >> Did you setenv ENABLE_STARTUP_LOCALE before calling ls? >> See environ(7) (-current). >For the most part stuff in -current might as well not exist as far as >I'm concerned. The X Consortium only supports released versions of any >particular OS, and then it officially only supports that same version >over the life of that particular release of X11. I'm already stretching >things as far as I can by running SNAP releases, and that's only because >I have faith that 2.1 will be real before our next release. (Not much of >a stretch really, our next release is months away.) It present since 2.0 and earlier. >That notwithstanding, I agree with Joerg, it's a hack and users shouldn't >have to resort to hacks to have things work correctly or reasonably, or >even reasonably correctly. I agree. My first idea was not introduce this hack, but I remeber some of core team members disagrees, so I add it. I can ether 1) Make it as default and not controlled by any variable. 2) Make it as default and controlled by DISABLE_STARTUP_LOCALE. >> >So I think the test isprint in ls really ought to be isgraph instead. >> >> It is a question. The only difference is space: isprint allows it and isgraph >> not. Does allowing spaces in file names considered bad? >> >In a separate context you cited the man page (and I think the man page is >wrong in that case.) Now I'm going to do the same thing. :-) The FreeBSD >man page for ls says that '?' is substituted for non-*graphical* characters >(and the SVR4 man page is in agreement. I wonder what POSIX says?) Since a I don't have Posix specs near me right now, so anybody with Posix please give more light on this subj. We need to follow Posix regardles of manpage/program or SVR4 currently does. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 16:46:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA15806 for hackers-outgoing; Sun, 15 Oct 1995 16:46:25 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA15801 for ; Sun, 15 Oct 1995 16:46:17 -0700 Received: by sequent.kiae.su id AA02878 (5.65.kiae-2 ); Mon, 16 Oct 1995 03:38:54 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 03:38:54 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id CAA00510; Mon, 16 Oct 1995 02:25:29 +0300 To: hackers@freefall.FreeBSD.org, "Kaleb S. KEITHLEY" References: <199510151747.NAA04827@exalt.x.org> In-Reply-To: <199510151747.NAA04827@exalt.x.org>; from "Kaleb S. KEITHLEY" at Sun, 15 Oct 1995 13:47:59 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 02:25:29 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 74 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3071 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510151747.NAA04827@exalt.x.org> Kaleb S. KEITHLEY writes: >Andrey Chernov said: >>>just fixing ls isn't enough. The default table of character types in >>>libc/locale/table.c isn't populated well enought to handle the whole >>>ISO8859-1 character set. The following patch fixes ls, libc, and also >>Default code table is ASCII and _not_ ISO8859-1, so it not needed to be >>populated. Default code table is strict 7bit. >No, it doesn't need to be, but is there a reason it can't do the right >thing anyway? The table is defined as having 256 elements, so populating >it with something useful isn't going to hurt anything. Historycally ctype(>127) returns 0 in many systems that I see, it means non-control, non-alpha, non-etc. If you want 8859-1, just use proper locale. >>>fixes some bugs in mklocale's lt_LN LC_CTYPE template. >>BLANK fixes are incorrect, see isblank(3). >Then the man page is wrong. The interpretation of blank on e.g. SVR4 >is that *only* '0x20' is a "blank". On at least one SVR4 system I have >here this is documented as specified by ISO8859-1. >Compatibility is a good thing. I think you should be compatible. If SVR4 do it, it isn't enough reason to do it too. Since isblank() isn't POSIX function, I prefer to see some standards and docs before change current behaviour. If you know such docs, please point me. >>XDIGIT fixes are right but ASCII locale used >>for digits and xdigits in any cases. >I'm not sure what this means. It means that isdigit/isxdigit works independent of current locale. They always refers to ASCII locale in FreeBSD. Ctype.h comment says that it is done by following ANSI standard. >>Other fixes which includes some additional big/lower letters probably >>can go, I need to check 8859-1 description first. >You can check if you want. :-) After checking I agree with you for letters range, as I already say I do commit based on this idea. >>BTW, xterm is known to dump core when any of 8bit locales set, >>f.e. ISO8859-1 or KOI8-R. color_xterm or mxterm works right. >>Can you track this bug, please? >What bug would this be? I'm not having any trouble at all running xterm >in ISO8859-1 locales on FreeBSD 2.1.0-950922-SNAP (and I wouldn't have >the first idea what to do in the KOI8-R locale :-)). You aren't by any >chance using XFree86's xterm are you? If so report the problem to them. xterm dumps core on startup when LANG variable set to one of existen locales expect "C". This bug present in SNAP you mention. Yes, I mean XFree86 xterm (I don't think they can be differ, but I am not shure). BTW, setting LANG to iso8859-1 does nothing, you need to specify full name like fr_FR.ISO_8859-1. On your snap second underscore maybe ommited, to be shure, check /usr/share/locale. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 16:47:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA15832 for hackers-outgoing; Sun, 15 Oct 1995 16:47:21 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA15825 for ; Sun, 15 Oct 1995 16:47:17 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id JAA01901; Mon, 16 Oct 1995 09:44:39 +1000 Date: Mon, 16 Oct 1995 09:44:39 +1000 From: Bruce Evans Message-Id: <199510152344.JAA01901@godzilla.zeta.org.au> To: pete@dsw.com, se@zpr.uni-koeln.de Subject: Re: Memory upgrade problems w/ 2.0.5R Cc: hackers@freefall.freebsd.org, hardware@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >} when building the kernel, I use optimizations (gcc 2.6.3): >} -O2 -m486 -fomit-frame-pointer -pipe >Hmm, is "-fomit-frame-pointer" legal >when compiling the kernel ??? >Maybe something depends on the stack >always being in "standard" format ? Only profiling and debugging should depend on the stack frame. Bruce From owner-freebsd-hackers Sun Oct 15 17:00:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA17590 for hackers-outgoing; Sun, 15 Oct 1995 17:00:50 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA17575 for ; Sun, 15 Oct 1995 17:00:47 -0700 Received: by sequent.kiae.su id AA04331 (5.65.kiae-2 ); Mon, 16 Oct 1995 03:51:43 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 03:51:42 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id CAA00650; Mon, 16 Oct 1995 02:50:43 +0300 To: FreeBSD hackers , Joerg Wunsch References: <199510152259.XAA22206@uriah.heep.sax.de> In-Reply-To: <199510152259.XAA22206@uriah.heep.sax.de>; from J Wunsch at Sun, 15 Oct 1995 23:59:43 +0100 (MET) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 02:50:43 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 23 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1078 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510152259.XAA22206@uriah.heep.sax.de> J Wunsch writes: >As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: >> >> I have nothing against reverting this variable to >> DISABLE_STARTUP_LOCALE f.e. If you remember I plan to make startup locale >> as default for all program, but some peoples disagree, so I introduce >> ENABLE_STARTUP_LOCALE. >The ENABLE_STARTUP_LOCALE hack is nice for those programs that are not >even aware of locale's. The base utilities however should be aware if >it, and handle it themselves. As i said in another message, except >perhaps daemons. All other utilities that use the isctype()-style >macros/functions should use it. You need to call completely non-standard function for all current sources cause portability problems. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 17:00:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA17630 for hackers-outgoing; Sun, 15 Oct 1995 17:00:58 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA17618 for ; Sun, 15 Oct 1995 17:00:55 -0700 Received: by sequent.kiae.su id AA04334 (5.65.kiae-2 ); Mon, 16 Oct 1995 03:51:44 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 03:51:44 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id CAA00639; Mon, 16 Oct 1995 02:49:36 +0300 To: hackers@freefall.freebsd.org, Joerg Wunsch References: <199510152256.XAA22059@uriah.heep.sax.de> In-Reply-To: <199510152256.XAA22059@uriah.heep.sax.de>; from J Wunsch at Sun, 15 Oct 1995 23:56:49 +0100 (MET) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 02:49:36 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 28 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1226 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510152256.XAA22059@uriah.heep.sax.de> J Wunsch writes: >As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: >> >> >IMHO, the base utilities that use should properly initialize >> >the locale instead of relying on that hack. >> >> You need different crt0 for native FreeBSD utilities and any other >> which you can compile, i.e. ports collection. >You misunderstood me. I was thinking of an explicit setlocale() >inside all system utilities (except daemons) that use . 1) Too match sources will be changed cause troubles with patches and upgrades. 2) It can be called twice, since first time call comes from crt0. 3) It is useful only for <=8bit locales, so you can't call setlocale, multichars becomes damaged, you need to call reduced to 8bit setlocale version as done in crt0. 4) Using non-standard (non-POSIX/ANSI/etc) reduced setlocale in all sources cause portability problems. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 17:01:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA17711 for hackers-outgoing; Sun, 15 Oct 1995 17:01:22 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA17701 for ; Sun, 15 Oct 1995 17:01:19 -0700 Received: by sequent.kiae.su id AA04327 (5.65.kiae-2 ); Mon, 16 Oct 1995 03:51:40 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 03:51:40 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id CAA00630; Mon, 16 Oct 1995 02:45:20 +0300 To: Bruce Evans , j@uriah.heep.sax.de Cc: hackers@freefall.freebsd.org, kaleb@x.org References: <199510152252.IAA32542@godzilla.zeta.org.au> In-Reply-To: <199510152252.IAA32542@godzilla.zeta.org.au>; from Bruce Evans at Mon, 16 Oct 1995 08:52:00 +1000 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 02:45:20 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 31 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1560 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510152252.IAA32542@godzilla.zeta.org.au> Bruce Evans writes: >>> Did you setenv ENABLE_STARTUP_LOCALE before calling ls? >>> See environ(7) (-current). >>IMHO, the base utilities that use should properly initialize >>the locale instead of relying on that hack. (The hack is useful to >>force programs that don't like to handle locale's, but base utilities >>of the system are expected to do it right theirselves.) >BTW, this hack adds 24K to the size of a minimal statically linked >program `main() {}' and defeats the point of most of the specially named >routines in crt0.c. E.g., there is a special version of getenv() named >_getenv() to avoid the namespace pollution and bloat from getenv(), but >the hack calls getenv() anyway; there are special versions of read() and >write(), but _startup_setlocale() references things in stdio that reference >read() and write(). And what? Now too many pgms require proper locale support, even ls, so we can't avoid this thing. Code added regardles of ENABLE_STARTUP_LOCALE set or not, so 'hack' means this variable as I understand and not code added. As I already say, I can revert default case to pick ctype and use variable DISABLE_STARTUP_LOCALE to disable it for debugging purposes. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 17:07:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA18694 for hackers-outgoing; Sun, 15 Oct 1995 17:07:10 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA18688 for ; Sun, 15 Oct 1995 17:07:08 -0700 Received: from exalt.x.org by expo.x.org id AA12908; Sun, 15 Oct 95 20:06:32 -0400 Received: from localhost by exalt.x.org id UAA06783; Sun, 15 Oct 1995 20:06:31 -0400 Message-Id: <199510160006.UAA06783@exalt.x.org> To: hackers@freefall.FreeBSD.org Cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Mon, 16 Oct 1995 00:03:59 EST. <199510152303.AAA22305@uriah.heep.sax.de> Organization: X Consortium Date: Sun, 15 Oct 1995 20:06:30 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > As Kaleb S. KEITHLEY wrote: > > > > As near as I can tell the SVR4 ls doesn't change its locale, yet still > > manages to do the right thing, probably because for most SVR4-en the C > > locale is full ISO8859-1. This leads me to believe that FreeBSD's ls > > probably doesn't need to change its locale either if the default chartype > > table is fully populated. > > So SVR4 would still break on koi8-r, for example. No it wouldn't because SVR4 doesn't have a koi8-r locale. If it has anything it probably is based on ISO8859-5, which, if I'm not mistaken, uses ASCII on the left side and Cyrillic on the right side; thus a multi- byte string like a file name might look different in one locale than in another. I have a perhaps naive presumption that if I created a multi-byte string in a particular locale that I would always try to look at it in the same locale. The only way to *really* solve this is to do something like use widechar strings in the file system and declare that all filenames are encoded in something like Unicode. Unless I misunderstood him, this is what Terry Lambert was lobbying for a couple of weeks ago, when he was asking for 16-bit wchar_t. This has all kinds of implications, but let's not go down that rathole right now. :-) > Either make it right, or let it be. Define right! I don't see it as wrong to populate the right half of the default chartype table with values that are useful in some particular locale -- in this case "C". No more wrong than leaving them blank. It is merely a convenience simple programs be able to do something useful for the majority of the users. Is the customer always right? If a particular tool isn't very useful in the general case, a customer might choose another another tool that is, in the general case, more useful. > > isctype() is not necessarily related to message catalogs. ??? I didn't say it was. I said that changing programs to set the locale was not very interesting (or necessary) unless you were going to make them use message catalogs for their output. >The > extensive (i.e. blatant) use of message catalogs (AIX, IRIX) leads to > very undesirable results, e.g. SMTP daemons throwing their error > messages in German. :-( It's hard for me to know how something like smtpd would get its locale set to de_DE in order to do that, but I wonder if that wouldn't be what I'd want if I were in Germany. From owner-freebsd-hackers Sun Oct 15 17:24:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA20326 for hackers-outgoing; Sun, 15 Oct 1995 17:24:29 -0700 Received: from gaboon.nai.net (gaboon.nai.net [204.71.31.225]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA20321 for ; Sun, 15 Oct 1995 17:24:26 -0700 Received: from localhost (freebsd@localhost) by gaboon.nai.net (8.6.5/8.6.6) id UAA15825 for hackers@freefall.freebsd.org; Sun, 15 Oct 1995 20:24:19 -0400 From: freebsd mail Message-Id: <199510160024.UAA15825@gaboon.nai.net> Subject: Kodak Photo CD mount? To: hackers@freefall.freebsd.org Date: Sun, 15 Oct 1995 20:24:18 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 389 Sender: owner-hackers@FreeBSD.org Precedence: bulk Hi! I can mount CD's all day with mount -t cd9660 /dev/cd0a /cdrom However, when I insert a Kodak Photo CD into the drive I get the following error: # mount -t cd9660 /dev/cd0a /cdrom cd9660: /dev/cd0a: Invalid argument # Please help! How do I mount a Koday photo CD? The drive is a: "TOSHIBA CD-ROM XM-3401TA 0283" type 5 removable SCSI 2 Thanks for the help, Stan asv@nai.net From owner-freebsd-hackers Sun Oct 15 17:29:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA20441 for hackers-outgoing; Sun, 15 Oct 1995 17:29:17 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA20436 for ; Sun, 15 Oct 1995 17:29:15 -0700 Received: from exalt.x.org by expo.x.org id AA13625; Sun, 15 Oct 95 20:28:37 -0400 Received: from localhost by exalt.x.org id UAA06809; Sun, 15 Oct 1995 20:28:36 -0400 Message-Id: <199510160028.UAA06809@exalt.x.org> To: hackers@freefall.FreeBSD.org Cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Mon, 16 Oct 1995 00:12:01 EST. <199510152312.AAA22414@uriah.heep.sax.de> Organization: X Consortium Date: Sun, 15 Oct 1995 20:28:36 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > As Kaleb S. KEITHLEY wrote: > > > > That notwithstanding, I agree with Joerg, it's a hack and users shouldn't > > have to resort to hacks to have things work correctly or reasonably, or > > even reasonably correctly. > > Speaking about internationalization, when will xbugs@x.org accept > mails with the 8th bit set? :--) > Oh good, I was hoping you'd bring this up. :-) Expo.x.org is our mail hub, it handles the xpert mailing list and dozens of other internal and external mailing lists. It has to work and it has to work correctly in order to maximize the probability of correct delivery of thousands of email messages each day. Expo follows RFC 821/822 to the letter. It's not convenient, but it does blindly adhere to the rules. Everyone else in the world seems to be overlooking the rules, mostly it seems because it's inconvenient to to follow the rules set out in the RFCs. Along the same line, it'd be really convenient if the default chartype table had its right side populated for ISO8859-1 so that broken tools could still manage to do the right thing most of the time. -- Kaleb From owner-freebsd-hackers Sun Oct 15 17:37:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA20689 for hackers-outgoing; Sun, 15 Oct 1995 17:37:49 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA20677 for ; Sun, 15 Oct 1995 17:37:44 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id KAA03511; Mon, 16 Oct 1995 10:36:51 +1000 Date: Mon, 16 Oct 1995 10:36:51 +1000 From: Bruce Evans Message-Id: <199510160036.KAA03511@godzilla.zeta.org.au> To: hackers@freefall.freebsd.org, kaleb@x.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Cc: ache@astral.msk.su Sender: owner-hackers@FreeBSD.org Precedence: bulk >>>just fixing ls isn't enough. The default table of character types in >>>libc/locale/table.c isn't populated well enought to handle the whole >>>ISO8859-1 character set. The following patch fixes ls, libc, and also >>Default code table is ASCII and _not_ ISO8859-1, so it not needed to be >>populated. Default code table is strict 7bit. >No, it doesn't need to be, but is there a reason it can't do the right >thing anyway? The table is defined as having 256 elements, so populating >it with something useful isn't going to hurt anything. The C standard. E.g., in the "C" locale, islower() and isupper() are specified as returning true only for the "C" lower and upper case letters. Thus in the ASCII table, _L and _U must not be set for characters >= 128. Bruce From owner-freebsd-hackers Sun Oct 15 17:37:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA20695 for hackers-outgoing; Sun, 15 Oct 1995 17:37:49 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA20681 for ; Sun, 15 Oct 1995 17:37:47 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id RAA07006; Sun, 15 Oct 1995 17:37:30 -0700 Message-Id: <199510160037.RAA07006@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: freebsd mail cc: hackers@freefall.freebsd.org Subject: Re: Kodak Photo CD mount? In-reply-to: Your message of "Sun, 15 Oct 1995 20:24:18 EDT." <199510160024.UAA15825@gaboon.nai.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 15 Oct 1995 17:37:29 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@FreeBSD.org Precedence: bulk >>> freebsd mail said: > Hi! > > I can mount CD's all day with mount -t cd9660 /dev/cd0a /cdrom > > However, when I insert a Kodak Photo CD into the drive I get the > following error: > > > > # mount -t cd9660 /dev/cd0a /cdrom > cd9660: /dev/cd0a: Invalid argument > # > > > Please help! How do I mount a Koday photo CD? > > The drive is a: "TOSHIBA CD-ROM XM-3401TA 0283" type 5 removable SCSI 2 > > Thanks for the help, > > Stan > asv@nai.net I doubt that the "TOSHIBA CD-ROM XM-3401T" can understand PhotoCDs. Due to the nature of what I do over here , playing VideoCDs, CD-I, and reading PhotoCDs , I ended up getting a Plextor 4Plex CDROM to be able to read various different CD formats. Amancio From owner-freebsd-hackers Sun Oct 15 17:40:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA20782 for hackers-outgoing; Sun, 15 Oct 1995 17:40:03 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA20769 for ; Sun, 15 Oct 1995 17:39:47 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id KAA05393; Mon, 16 Oct 1995 10:41:47 +0930 From: Michael Smith Message-Id: <199510160111.KAA05393@genesis.atrad.adelaide.edu.au> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Mon, 16 Oct 1995 10:41:46 +0930 (CST) Cc: hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de In-Reply-To: <199510160006.UAA06783@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 15, 95 08:06:30 pm Content-Type: text Content-Length: 1207 Sender: owner-hackers@FreeBSD.org Precedence: bulk Kaleb S. KEITHLEY stands accused of saying: > >The > > extensive (i.e. blatant) use of message catalogs (AIX, IRIX) leads to > > very undesirable results, e.g. SMTP daemons throwing their error > > messages in German. :-( > > It's hard for me to know how something like smtpd would get its locale > set to de_DE in order to do that, but I wonder if that wouldn't be what > I'd want if I were in Germany. I'll second that 8) The AIX/OS2 etc standard of "(reference) message" is still my favorite - the messages are usually verbose and at least vaguely informative, and the numbers mean that when a luser is reading it to you over the 'phone, that's all you need, coz you can look it up locally. (And thus it doesn't matter what language the message is in, because you can regenerate it at will with the catalog lookup tool) -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Sun Oct 15 17:45:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA21002 for hackers-outgoing; Sun, 15 Oct 1995 17:45:47 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA20996 for ; Sun, 15 Oct 1995 17:45:45 -0700 Received: by sequent.kiae.su id AA08429 (5.65.kiae-2 ); Mon, 16 Oct 1995 04:31:35 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 04:31:35 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id DAA01086; Mon, 16 Oct 1995 03:31:12 +0300 To: hackers@freefall.FreeBSD.org, "Kaleb S. KEITHLEY" Cc: Joerg Wunsch References: <199510160006.UAA06783@exalt.x.org> In-Reply-To: <199510160006.UAA06783@exalt.x.org>; from "Kaleb S. KEITHLEY" at Sun, 15 Oct 1995 20:06:30 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 03:31:11 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 27 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1383 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510160006.UAA06783@exalt.x.org> Kaleb S. KEITHLEY writes: >> Either make it right, or let it be. >Define right! I don't see it as wrong to populate the right half of the >default chartype table with values that are useful in some particular >locale -- in this case "C". No more wrong than leaving them blank. It >is merely a convenience simple programs be able to do something useful >for the majority of the users. Is the customer always right? If a >particular tool isn't very useful in the general case, a customer might >choose another another tool that is, in the general case, more useful. What you mean by majority? Russian users amount is comparable with all european users, why not extend default table to KOI8-R instead? Seriously, pure ASCII variant need to be keeped in any case, and it is only one valid *default* case, because it is subset for almost all known charsets. Preferring one particular charset among others leeds into various troubles. I dislike X idea to have ISO8859-1 as default charset and think that they need to change it to ASCII. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 17:46:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA21032 for hackers-outgoing; Sun, 15 Oct 1995 17:46:25 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA21027 for ; Sun, 15 Oct 1995 17:46:17 -0700 Received: by sequent.kiae.su id AA09733 (5.65.kiae-2 ); Mon, 16 Oct 1995 04:42:54 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 04:42:53 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id DAA01149; Mon, 16 Oct 1995 03:42:11 +0300 To: hackers@freefall.FreeBSD.org, "Kaleb S. KEITHLEY" Cc: Joerg Wunsch References: <199510160028.UAA06809@exalt.x.org> In-Reply-To: <199510160028.UAA06809@exalt.x.org>; from "Kaleb S. KEITHLEY" at Sun, 15 Oct 1995 20:28:36 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 03:42:11 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 38 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1542 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510160028.UAA06809@exalt.x.org> Kaleb S. KEITHLEY writes: >> As Kaleb S. KEITHLEY wrote: >> > >> > That notwithstanding, I agree with Joerg, it's a hack and users shouldn't >> > have to resort to hacks to have things work correctly or reasonably, or >> > even reasonably correctly. >> >> Speaking about internationalization, when will xbugs@x.org accept >> mails with the 8th bit set? :--) >> >Expo follows RFC 821/822 to the letter. It's not convenient, but it does >blindly adhere to the rules. Everyone else in the world seems to be >overlooking the rules, mostly it seems because it's inconvenient to >to follow the rules set out in the RFCs. Why not use ESMTP there? It is transparent fot 8bit and not require charsets management. >Along the same line, it'd be really convenient if the default chartype >table had its right side populated for ISO8859-1 so that broken tools >could still manage to do the right thing most of the time. Why touch default table? You can setup 8859-1 locale in your /etc/rc file for all daemons. BTW, just cheking, POSIX agree with me that "C" locale must be pure ASCII, so we can safely close this subject about table propogating. Your idea about 8859-1 propogating violates POSIX. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 18:01:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA21325 for hackers-outgoing; Sun, 15 Oct 1995 18:01:03 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA21314 for ; Sun, 15 Oct 1995 18:01:00 -0700 Received: from exalt.x.org by expo.x.org id AA14487; Sun, 15 Oct 95 21:00:28 -0400 Received: from localhost by exalt.x.org id VAA06828; Sun, 15 Oct 1995 21:00:28 -0400 Message-Id: <199510160100.VAA06828@exalt.x.org> To: ache@astral.msk.su Cc: hackers@freefall.FreeBSD.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Mon, 16 Oct 1995 02:25:29 EST. Organization: X Consortium Date: Sun, 15 Oct 1995 21:00:27 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > In message <199510151747.NAA04827@exalt.x.org> Kaleb S. KEITHLEY > writes: > > >Andrey Chernov said: > > >>>just fixing ls isn't enough. The default table of character types in > >>>libc/locale/table.c isn't populated well enought to handle the whole > >>>ISO8859-1 character set. The following patch fixes ls, libc, and also > > >>Default code table is ASCII and _not_ ISO8859-1, so it not needed to be > >>populated. Default code table is strict 7bit. > > >No, it doesn't need to be, but is there a reason it can't do the right > >thing anyway? The table is defined as having 256 elements, so populating > >it with something useful isn't going to hurt anything. > > Historycally ctype(>127) returns 0 in many systems that I see, Every day that goes by there are fewer and fewer people using those systems. Just because the U.S.-centric computer industry used to have tunnel vision when it came to i18n doesn't mean that "modern" systems should perpetuate the same mistakes into the future, especially when there's no reason not to fix it. > If you want 8859-1, just use proper locale. A nice suggestion. Too bad it doesn't work. ANSI/POSIX1 say that a program does the equivalent of setlocale(LC_ALL, "C") on startup. Given that ls, and I gather everything else, disregard my LANG, LC_ALL, and LC_CTYPE environment variables, I'm left wondering how it is you think that using the "proper locale" will help. Are you assuming that I'm using the undocumented hack of setting the ENABLE_STARTUP_LOCALE environment variable? > >>>fixes some bugs in mklocale's lt_LN LC_CTYPE template. > > >>BLANK fixes are incorrect, see isblank(3). > > >Then the man page is wrong. The interpretation of blank on e.g. SVR4 > >is that *only* '0x20' is a "blank". On at least one SVR4 system I have > >here this is documented as specified by ISO8859-1. > > >Compatibility is a good thing. I think you should be compatible. > > If SVR4 do it, it isn't enough reason to do it too. Since isblank() > isn't POSIX function, I prefer to see some standards and docs before > change current behaviour. If you know such docs, please point me. As I said, at least one system's docs claim it spec'd in ISO8859-1. I don't have an ISO8859-1 at hand, and I'm not even sure I have one at work, although I must, somewhere. > >>BTW, xterm is known to dump core when any of 8bit locales set, > >>f.e. ISO8859-1 or KOI8-R. color_xterm or mxterm works right. > >>Can you track this bug, please? > > >What bug would this be? I'm not having any trouble at all running xterm > >in ISO8859-1 locales on FreeBSD 2.1.0-950922-SNAP (and I wouldn't have > >the first idea what to do in the KOI8-R locale :-)). You aren't by any > >chance using XFree86's xterm are you? If so report the problem to them. > > xterm dumps core on startup when LANG variable set to one of > existen locales expect "C". This bug present in SNAP you mention. As I said, I don't have any problem with xterm, and no, I'm not using the "C" locale. > Yes, I mean XFree86 xterm (I don't think they can be differ, > but I am not shure). I am sure. They are different, that's why I asked. -- Kaleb From owner-freebsd-hackers Sun Oct 15 18:07:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA21449 for hackers-outgoing; Sun, 15 Oct 1995 18:07:06 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA21444 for ; Sun, 15 Oct 1995 18:07:03 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id LAA04297; Mon, 16 Oct 1995 11:01:25 +1000 Date: Mon, 16 Oct 1995 11:01:25 +1000 From: Bruce Evans Message-Id: <199510160101.LAA04297@godzilla.zeta.org.au> To: ache@astral.msk.su, bde@zeta.org.au, hackers@freefall.freebsd.org, kaleb@x.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Sender: owner-hackers@FreeBSD.org Precedence: bulk >Bruce, I agree with you and POSIX agree with us. >Default table must be strict ASCII per POSIX. >So, we can close this table propogating subject. Does POSIX mention ASCII? ANSI allows other encodings of course, and is only strict for letters and digits, but only letters are very important. Bruce From owner-freebsd-hackers Sun Oct 15 18:15:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA21622 for hackers-outgoing; Sun, 15 Oct 1995 18:15:47 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA21616 for ; Sun, 15 Oct 1995 18:15:44 -0700 Received: by sequent.kiae.su id AA13174 (5.65.kiae-2 ); Mon, 16 Oct 1995 05:14:46 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 05:14:45 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id EAA01277; Mon, 16 Oct 1995 04:13:55 +0300 To: "Kaleb S. KEITHLEY" Cc: hackers@freefall.FreeBSD.org References: <199510160100.VAA06828@exalt.x.org> In-Reply-To: <199510160100.VAA06828@exalt.x.org>; from "Kaleb S. KEITHLEY" at Sun, 15 Oct 1995 21:00:27 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 04:13:55 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 54 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2404 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510160100.VAA06828@exalt.x.org> Kaleb S. KEITHLEY writes: >> Historycally ctype(>127) returns 0 in many systems that I see, >Every day that goes by there are fewer and fewer people using those >systems. Just because the U.S.-centric computer industry used to have >tunnel vision when it came to i18n doesn't mean that "modern" systems >should perpetuate the same mistakes into the future, especially when >there's no reason not to fix it. I agree. But disagree of your default touching. POSIX says that "C" locale must be strict ASCII. >> If you want 8859-1, just use proper locale. >A nice suggestion. Too bad it doesn't work. ANSI/POSIX1 say that a >program does the equivalent of setlocale(LC_ALL, "C") on startup. Given >that ls, and I gather everything else, disregard my LANG, LC_ALL, and >LC_CTYPE environment variables, I'm left wondering how it is you think >that using the "proper locale" will help. Are you assuming that I'm >using the undocumented hack of setting the ENABLE_STARTUP_LOCALE >environment variable? Yes, for FreeBSD I assume this. Some other systems, like Xenix with international support and some Sun's locale variants call setlocale() from crt0 without additional asking. Basically you must cleanup your ctype-oriented program to work with multi-byte chars before inserting setlocale() call into main(). Don't forget: ctype famaly works with multi-byte chars too. If you simple insert setlocale in 'ls' f.e. it becomes very broken for Japanese chars f.e. because it assumed that char type == char everywhere. My strategy allows to 'ls' stays to ASCII when LANG sets to Japanese. If 'ls' stays to 8859-1 as you suggest, it overwrites chars in Japanese environment! >> >>>fixes some bugs in mklocale's lt_LN LC_CTYPE template. >> >> >>BLANK fixes are incorrect, see isblank(3). >> >As I said, at least one system's docs claim it spec'd in ISO8859-1. I >don't have an ISO8859-1 at hand, and I'm not even sure I have one at >work, although I must, somewhere. I don't need 8859-1 docs, I already have them. I need any isblank() references. Maybe ANSI? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 18:41:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA21991 for hackers-outgoing; Sun, 15 Oct 1995 18:41:33 -0700 Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA21985 for ; Sun, 15 Oct 1995 18:41:27 -0700 Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id LAA02341; Mon, 16 Oct 1995 11:39:32 +1000 From: David Dawes Message-Id: <199510160139.LAA02341@rf900.physics.usyd.edu.au> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Mon, 16 Oct 1995 11:39:32 +1000 (EST) Cc: ache@astral.msk.su, hackers@freefall.freebsd.org In-Reply-To: <199510160100.VAA06828@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 15, 95 09:00:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1219 Sender: owner-hackers@FreeBSD.org Precedence: bulk >> >>BTW, xterm is known to dump core when any of 8bit locales set, >> >>f.e. ISO8859-1 or KOI8-R. color_xterm or mxterm works right. >> >>Can you track this bug, please? >> >> >What bug would this be? I'm not having any trouble at all running xterm >> >in ISO8859-1 locales on FreeBSD 2.1.0-950922-SNAP (and I wouldn't have >> >the first idea what to do in the KOI8-R locale :-)). You aren't by any >> >chance using XFree86's xterm are you? If so report the problem to them. >> >> xterm dumps core on startup when LANG variable set to one of >> existen locales expect "C". This bug present in SNAP you mention. > >As I said, I don't have any problem with xterm, and no, I'm not using >the "C" locale. > >> Yes, I mean XFree86 xterm (I don't think they can be differ, >> but I am not shure). > >I am sure. They are different, that's why I asked. Yes, they are different. Can someone give me a precise method of reproducing this problem? I routinely have LANG set to en_AU.ISO8859-1 on my 2.0.5 system. I've also tried with it set to ru_SU.KOI8-R without a problem. I'm using the version of xterm in XFree86 3.1.2. I don't have ENABLE_STARTUP_LOCALE (or any other LANG stuff) enabled in /etc/sysconfig. David From owner-freebsd-hackers Sun Oct 15 18:42:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA22023 for hackers-outgoing; Sun, 15 Oct 1995 18:42:49 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA22018 for ; Sun, 15 Oct 1995 18:42:45 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id LAA05419; Mon, 16 Oct 1995 11:42:07 +1000 Date: Mon, 16 Oct 1995 11:42:07 +1000 From: Bruce Evans Message-Id: <199510160142.LAA05419@godzilla.zeta.org.au> To: matt@lkg.dec.com, se@zpr.uni-koeln.de Subject: Re: IPX now available Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >significant sense. However, when the world is dynamic the autoconfig >code now becomes passive and the LKMs are the active components. >Indeed, one very real way to look at this would be to use the DATA_SET >capabilities that currently exist to store a vector of configuration/ >initialization entries. So when the kernel is linked, all the >initializers for devices, file systems, protocols, etc. are present in >this data set. The system will define a set of synchronization points and >ordering points within each sync point. So when the kernel initializes, it >sorts these configuration entries and calls them one by one in order. >This results in a number of benifits. The first is that the exact same >modules can be used for both static-linked kernel and dynamically loaded >kernel. Another benifit is that you can develop and debug almost all >the mechanisms needed for a truly dynamic kernel using the existing static >kernel framework. I think this is backwards. I see linker vectors as just a trick to help initialize things when you don't have fully dynamic initialization. I think the static framework should be changed to look more like the dynamic framework instead of vice versa. >... >I strongly disagree. In my view, a LKM controls its own fate. The kernel >(or other LKMs on which this LKM depends) merely provided services which it >can use. Indeed, as far as the system is concerned there should be no >difference between a FS LKM or a device LKM or protocol LKM or a syscall LKM. >Once the LKM's configuration entry point has been called, the LKM is in >control. Yes, the dynamic framework (at least for device drivers) should be: . a single entry point (for initialization) in each module . autonomous modules The only difference for the static framework should be that the list of initialization routines is kept in a vector instead of in a file. Vectors aren't suitable for handling complicated orderings. The linker may put things in the wrong order so you need a meta-routine to decide the order or more intelligence in the module initialization routines. I think that except for early kernel initialization, all the intelligence should be in the module initialization routines. Device drivers will need to be able to sleep in their probe and attach routines for other reasons. When tsleep() at probe and attach time is implemented, complicated time-dependent orderings (aka races :-) will be easy to implemented - just sleep until the modules that you depend on are loaded. Bruce From owner-freebsd-hackers Sun Oct 15 18:46:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA22147 for hackers-outgoing; Sun, 15 Oct 1995 18:46:07 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA22142 for ; Sun, 15 Oct 1995 18:45:59 -0700 Received: by sequent.kiae.su id AA17801 (5.65.kiae-2 ); Mon, 16 Oct 1995 05:45:23 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 05:45:23 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id EAA01396; Mon, 16 Oct 1995 04:44:58 +0300 To: bde@zeta.org.au, hackers@freefall.freebsd.org, kaleb@x.org References: <199510160101.LAA04297@godzilla.zeta.org.au> In-Reply-To: <199510160101.LAA04297@godzilla.zeta.org.au>; from Bruce Evans at Mon, 16 Oct 1995 11:01:25 +1000 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 04:44:58 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 325 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 7939 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510160101.LAA04297@godzilla.zeta.org.au> Bruce Evans writes: >>Bruce, I agree with you and POSIX agree with us. >>Default table must be strict ASCII per POSIX. >>So, we can close this table propogating subject. >Does POSIX mention ASCII? ANSI allows other encodings >of course, and is only strict for letters and digits, >but only letters are very important. Well 1003.1 says something about minimal subset to run C pgms. Comparing ASCII and 8859-1 is clear that ASCII is more minimal. Here some explanation of this term taken directly from POSIX working gtoup ISO/IEC JTC1/SC22/WG15 - POSIX: locale collection. They have VERY different locales for POSIX default and 8859-1 and POSIX default conforms ASCII, see below. (If someone interested, I can post their 8859-1 locale too). ------------------------------------------------------------------ # POSIX Standard Locale # # As per ISO/IEC 9945-2:1993 specifications # except for these additional identifying comments # # Source: ISO/IEC JTC1/SC22/WG15 RIN # Address: C/O DKUUG, Fruebjergvej 3 # DK-2900 Copenhagen O, Denmark # Contact: Keld Simonsen # Email: Keld.Simonsen@dkuug.dk # Tel: +45 - 39179944 # Fax: +45 - 39179897 # Language: POSIX # Territory: # Revision: 1.0 # Date: 1994-04-02 # Application: general # Users: general # Repertoiremap: POSIX # Charset: ISO646:1993 # Distribution and use is free, also for # commercial purposes. LC_CTYPE # The following is the POSIX Locale LC_CTYPE. # "alpha" is by default "upper" and "lower" # "alnum" is by definiton "alpha" and "digit" # "print" is by default "alnum", "punct" and the character # "graph" is by default "alnum" and "punct" # upper ;;;;;;;;;;;;\ ;;

;;;;;;;;;; # digit ;;;;;\ ;;;; # space ;;;;\ ; # cntrl ;;;;;\ ;;\ ;;;;;;;;\ ;;;;;;;;;\ ;;;;;;; # punct ;;;\ ;;;;\ ;;;\ ;;;;;\ ;;;;\ ;;;\ ;;;\ ;;;\ ;;;; # xdigit ;;;;;;;;;\ ;;;;;;;;;;;; # blank ; # tolower (,);(,);(,);(,);(,);\ (,);(,);(,);(,);(,);\ (,);(,);(,);(,);(,);\ (

,

);(,);(,);(,);(,);\ (,);(,);(,);(,);(,);(,); # toupper (,);(,);(,);(,);(,);\ (,);(,);(,);(,);(,);\ (,);(,);(,);(,);(,);\ (

,

);(,);(,);(,);(,);\ (,);(,);(,);(,);(,);(,); END LC_CTYPE LC_COLLATE # This is the POSIX Locale definition for the LC_COLLATE category. # The order is the same as in the ASCII code set. order_start forward

order_end # END LC_COLLATE LC_MONETARY # This is the POSIX Locale definition for # the LC_MONETARY category. # int_curr_symbol "" currency_symbol "" mon_decimal_point "" mon_thousands_sep "" mon_grouping -1 positive_sign "" negative_sign "" int_frac_digits -1 frac_digits -1 p_cs_precedes -1 p_sep_by_space -1 n_cs_precedes -1 n_sep_by_space -1 p_sign_posn -1 n_sign_posn -1 # END LC_MONETARY LC_NUMERIC # This is the POSIX Locale definition for # the LC_NUMERIC category. # decimal_point "" thousands_sep "" grouping -1 # END LC_NUMERIC LC_TIME # This is the POSIX Locale definition for # the LC_TIME category. # # Abbreviated weekday names (%s) abday "";"";"";"";\ "";"";"" # # Full weekday names (%A) day "";"";\ "";"";\ "";"";\ "" # # Abbreviated month names (%b) abmon "";"";"";\ "

";"";"";\ "";"";"

";\ "";"";"" # # Full month names (%B) mon "";"";\ "";"

";\ "";"";\ "";"";\ "

";"";\ "";"" # # Equivalent of AM/PM (%p) "AM"/"PM" am_pm "";"

" # # Appropriate date and time representation (%c) # "%a %b %e %H:%M:%S %Y" d_t_fmt "\ \ " # # Appropriate date representation (%x) "%m/%d/%y" d_fmt "" # # Appropriate time representation (%X) "%H:%M:%S" t_fmt "" # # Appropriate 12 h time representation (%Xr "%I:%M:%S %p" t_fmt_ampm "

" # END LC_TIME LC_MESSAGES # This is the POSIX Locale definition for # the LC_NUMERIC category. # yesexpr "" # noexpr "" END LC_MESSAGES -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 18:55:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA22286 for hackers-outgoing; Sun, 15 Oct 1995 18:55:37 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA22281 for ; Sun, 15 Oct 1995 18:55:34 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id LAA05631; Mon, 16 Oct 1995 11:56:27 +0930 From: Michael Smith Message-Id: <199510160226.LAA05631@genesis.atrad.adelaide.edu.au> Subject: Re: three-stage boot To: uhclem%nemesis@fw.ast.com (Frank Durda IV) Date: Mon, 16 Oct 1995 11:56:26 +0930 (CST) Cc: hackers@freebsd.org In-Reply-To: from "Frank Durda IV" at Oct 13, 95 08:46:00 am Content-Type: text Content-Length: 1561 Sender: owner-hackers@freebsd.org Precedence: bulk Frank Durda IV stands accused of saying: > > [0]Speaking of the three-stage boot stuff, I'd like to hear from some/anyone > [0]that has a set of screen, serial and disk libraries that interact directly > [0]with the BIOS in the state that it's in when the bootsector is loaded. > > Yeah, I have some of this stuff from the XENIX days. The filesystem > stuff would have to be replaced, but I assume all you are interested in > is mainly the stuff for getting the BIOS to read the hard disk > and maybe keep the user informed on progress, right? Er, no. In the short term, the idea would be to dumb down the second-stage bootloader, and shift the bloat into the third stage, which would probably be in a file called /boot. This tool should eventually be able to absorb userconfig and a kernel selector, and be able to decompress kernels as they're being read, as well as growing any number of other features. This would need some disk and console support, and it's not going to have an OS behind it to provide it, just the BIOS. > I'll dig this stuff up if you want it. Any resources are welcome. > Frank Durda IV |"Remember, Bill is getting -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Sun Oct 15 19:01:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA22393 for hackers-outgoing; Sun, 15 Oct 1995 19:01:24 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA22388 for ; Sun, 15 Oct 1995 19:01:20 -0700 Received: by sequent.kiae.su id AA18738 (5.65.kiae-2 ); Mon, 16 Oct 1995 05:54:44 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 05:54:44 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id EAA01445; Mon, 16 Oct 1995 04:52:55 +0300 To: David Dawes , "Kaleb S. KEITHLEY" Cc: hackers@freefall.freebsd.org References: <199510160139.LAA02341@rf900.physics.usyd.edu.au> In-Reply-To: <199510160139.LAA02341@rf900.physics.usyd.edu.au>; from David Dawes at Mon, 16 Oct 1995 11:39:32 +1000 (EST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 04:52:54 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 27 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1273 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510160139.LAA02341@rf900.physics.usyd.edu.au> David Dawes writes: >Yes, they are different. Can someone give me a precise method of >reproducing this problem? I routinely have LANG set to en_AU.ISO8859-1 >on my 2.0.5 system. I've also tried with it set to ru_SU.KOI8-R without >a problem. I'm using the version of xterm in XFree86 3.1.2. I don't have >ENABLE_STARTUP_LOCALE (or any other LANG stuff) enabled in /etc/sysconfig. Try to setenv ENABLE_STARTUP_LOCALE before running xterm (from shell, not from sysconfig). Since I delete my xterm copy replacing it by color_xterm due to this bug, can you upload your xterm binaries somewhere to freefall, so I can tell you exact sequence to bring the bug? See also old message with subject: Subject: bug: 2.0.5-R: ENABLE_STARTUP_LOCALE + xterm = SIGSEGV in -hackers list which reports the same bug. Very recently someone reports the same bug into -current list with fr_FR locale, speaking about phkmalloc. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 19:47:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA23148 for hackers-outgoing; Sun, 15 Oct 1995 19:47:58 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA23142 for ; Sun, 15 Oct 1995 19:47:52 -0700 Received: by sovcom.kiae.su id AA17184 (5.65.kiae-1 ); Mon, 16 Oct 1995 05:47:28 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 05:47:28 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id FAA00188; Mon, 16 Oct 1995 05:45:56 +0300 To: "Kaleb S. KEITHLEY" Cc: hackers@freefall.FreeBSD.org References: <199510160100.VAA06828@exalt.x.org> In-Reply-To: ; from =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= at Mon, 16 Oct 1995 04:13:55 +0300 (MSK) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 05:45:55 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 31 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1355 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= writes: >>A nice suggestion. Too bad it doesn't work. ANSI/POSIX1 say that a >>program does the equivalent of setlocale(LC_ALL, "C") on startup. Given >>that ls, and I gather everything else, disregard my LANG, LC_ALL, and >>LC_CTYPE environment variables, I'm left wondering how it is you think >>that using the "proper locale" will help. Are you assuming that I'm >>using the undocumented hack of setting the ENABLE_STARTUP_LOCALE >>environment variable? Well, more simplest example: 1) Assume that startup locale hack not exist. 2) Assume that default table propogated to 8859-1 as you suggest. 3) Assume I set use KOI8-R locale/codetable on my system. In that was I got some strange KOI8-R chars in various places because they match some letters from 8859-1! When default table is strictly ASCII, I don't see strange KOI8-R chars because they are disabled as supposed. So, I can't let European users live by price Russian/Japanese/etc. users death. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 21:20:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA25060 for hackers-outgoing; Sun, 15 Oct 1995 21:20:40 -0700 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA25055 for ; Sun, 15 Oct 1995 21:20:36 -0700 Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA27175; Mon, 16 Oct 1995 00:20:04 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 16 Oct 1995 00:20 EDT Received: from lakes (lakes [192.96.3.39]) by ponds.UUCP (8.6.11/8.6.5) with ESMTP id WAA21478; Sun, 15 Oct 1995 22:00:16 -0400 Received: (from rivers@localhost) by lakes (8.6.11/8.6.9) id VAA01958; Sun, 15 Oct 1995 21:59:20 -0400 Date: Sun, 15 Oct 1995 21:59:20 -0400 From: Thomas David Rivers Message-Id: <199510160159.VAA01958@lakes> To: rah.star-gate.com!hasty@dg-rtp.dg.com, ponds!rivers Subject: Re: Recording from SB16 in 2.0.5? Cc: dg-rtp.dg.com!ponds!rivers@sbstark.cs.sunysb.edu, gene@starkhome.cs.sunysb.edu, hackers@freebsd.org Content-Type: text Content-Length: 940 Sender: owner-hackers@freebsd.org Precedence: bulk Amancio said: > > > Thomas David Rivers said: > > > > > > >Has anyone been successful at recording sound with the sound-blaster-16 > > > >driver in 2.0.5? > > > > > > Not in 2.0.5, but in -stable it works OK with NAS, vmix, or just > > > catting /dev/audio. > > > > > > - Gene > > > > > > > Okey-Dokey - > > > > I'll wait for 2.1 and try it then. > > > > Or, you can grab the sound driver from -stable and try it. > tar -cf sound.tar --stable-/sys/i386/isa/sound > then on your system , > cd /sys/i386/isa > mv sound sound.old > tar -xf sound.tar > > rebuild the kernel and off you go ... > > Amancio > I'll give it a shot.. but I'm a little confused by exactly what "--stable-/sys/i386/isa/sound" is... I think I still have an account on freefall; but I'm not up on how to use CVS, etc... Is there a copy of the --stable tree there I can just grab this from? - Thanks - - Dave Rivers - From owner-freebsd-hackers Sun Oct 15 21:33:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA25368 for hackers-outgoing; Sun, 15 Oct 1995 21:33:01 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA25354 for ; Sun, 15 Oct 1995 21:32:56 -0700 Received: by sovcom.kiae.su id AA26575 (5.65.kiae-1 ); Mon, 16 Oct 1995 07:24:18 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 07:24:18 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id HAA00242; Mon, 16 Oct 1995 07:21:56 +0300 To: "Kaleb S. KEITHLEY" Cc: hackers@freefall.FreeBSD.org References: <199510160100.VAA06828@exalt.x.org> In-Reply-To: ; from =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= at Mon, 16 Oct 1995 04:13:55 +0300 (MSK) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 07:21:56 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 26 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1126 Sender: owner-hackers@FreeBSD.org Precedence: bulk >In message <199510160100.VAA06828@exalt.x.org> Kaleb S. KEITHLEY > writes: >>> If you want 8859-1, just use proper locale. >>A nice suggestion. Too bad it doesn't work. ANSI/POSIX1 say that a >>program does the equivalent of setlocale(LC_ALL, "C") on startup. Given >>that ls, and I gather everything else, disregard my LANG, LC_ALL, and >>LC_CTYPE environment variables, I'm left wondering how it is you think >>that using the "proper locale" will help. Are you assuming that I'm >>using the undocumented hack of setting the ENABLE_STARTUP_LOCALE >>environment variable? Briefly says, I disagree with default table propogation to 8859-1 (well, maybe agree with propogation to KOI8-R :-) because: 1) It violates POSIX default "C" locale description. 2) It breaks all >=8bit charsets which names != 8859-1. Pretty enough. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 22:22:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA26069 for hackers-outgoing; Sun, 15 Oct 1995 22:22:27 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA26064 for ; Sun, 15 Oct 1995 22:22:21 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA11669; Mon, 16 Oct 1995 15:16:12 +1000 Date: Mon, 16 Oct 1995 15:16:12 +1000 From: Bruce Evans Message-Id: <199510160516.PAA11669@godzilla.zeta.org.au> To: ache@astral.msk.su, bde@zeta.org.au, j@uriah.heep.sax.de Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Cc: hackers@freefall.freebsd.org, kaleb@x.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >>BTW, this hack adds 24K to the size of a minimal statically linked >>program `main() {}' and defeats the point of most of the specially named >>routines in crt0.c. E.g., there is a special version of getenv() named >And what? Now too many pgms require proper locale support, even ls, >so we can't avoid this thing. Code added regardles of >ENABLE_STARTUP_LOCALE set or not, Yes, bloat is added even when ENABLE_STARTUP_LOCALE isn't set. Bloat is added even when no ctype function is called (this is normal for most programs in /bin and /sbin - grep shows "ctype.h" in only 25 out of 80 programs in /usr/src/[s]bin. >so 'hack' means this variable >as I understand and not code added. As I already say, For me, the `hack' is the global placement of the test. It's good for fixing everything at once, but is wasteful. >I can revert default case to pick ctype and use variable >DISABLE_STARTUP_LOCALE to disable it for debugging purposes. This wouldn't reduce the bloat because lots of code is required to pull in the default locale. More measurements: size of /bin/cat with locale support: 64K size of /bin/cat without locale support: 44K (cat uses ctype only for cat -v) time for 1000 fork+execs with ENABLE_STARTUP_LOCALE unset: 92.81 real 6.47 user 76.68 sys time for 1000 fork+execs with ENABLE_STARTUP_LOCALE set and LANG set to it_IT.ISO_8859-1: 112.58 real 15.43 user 94.89 sys Bruce From owner-freebsd-hackers Sun Oct 15 22:56:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA26975 for hackers-outgoing; Sun, 15 Oct 1995 22:56:57 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id WAA26969 for ; Sun, 15 Oct 1995 22:56:55 -0700 Received: by sovcom.kiae.su id AA04994 (5.65.kiae-1 ); Mon, 16 Oct 1995 08:46:21 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 08:46:21 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id IAA00223; Mon, 16 Oct 1995 08:43:11 +0300 To: bde@zeta.org.au, j@uriah.heep.sax.de Cc: hackers@freefall.freebsd.org, kaleb@x.org References: <199510160516.PAA11669@godzilla.zeta.org.au> In-Reply-To: <199510160516.PAA11669@godzilla.zeta.org.au>; from Bruce Evans at Mon, 16 Oct 1995 15:16:12 +1000 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 08:43:10 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 32 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1397 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510160516.PAA11669@godzilla.zeta.org.au> Bruce Evans writes: >Yes, bloat is added even when ENABLE_STARTUP_LOCALE isn't set. Bloat is >added even when no ctype function is called (this is normal for most >programs in /bin and /sbin - grep shows "ctype.h" in only 25 out of 80 >programs in /usr/src/[s]bin. It isn't accurate results. Many libc functions calls ctype indirecly, i.e. strtol, atoi, etc. You additionly need to grep ctype through libc and then grep function you got through bin/sbin. I suspect that 100% of programs use ctype for accurate results. >>I can revert default case to pick ctype and use variable >>DISABLE_STARTUP_LOCALE to disable it for debugging purposes. >This wouldn't reduce the bloat because lots of code is required to >pull in the default locale. 1) I don't care of bloat on my proposal, I care of easy way of locale using. 2) We already discuss that bloat on early days and agree let it be. 3) I don't see proper way to avoid it for statically compiled pgms, so I don't understand what we can discuss here. Yes it isn't very good. Alternatives? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Oct 15 22:57:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA27008 for hackers-outgoing; Sun, 15 Oct 1995 22:57:59 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA27002 for ; Sun, 15 Oct 1995 22:57:51 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id HAA23316; Mon, 16 Oct 1995 07:57:42 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id HAA25208; Mon, 16 Oct 1995 07:57:41 +0200 Message-Id: <199510160557.HAA25208@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: Dave Hayes cc: hackers@freebsd.org Subject: Re: Creating a /dev/random Date: Mon, 16 Oct 1995 07:57:41 +0200 From: Mark Murray Sender: owner-hackers@freebsd.org Precedence: bulk > Mark Murray writes: > >I am building devices, /dev/random and /dev/urandom that when read give > >random noise generated in and by the kernel. > > How is this noise generated? Is it really random, by statistical > tests? It is very random, and I believe it will survive the most rigorous tests. The code maintains a pool of entropy, which is added to by system events such as interrupts, timer events eystrokes etc. As entropy is removed, the entropy count is reduced, and as events come in, this is increased. If you like, I can forward the code... > Is there any chance of having an option to take random bits from an > existing sound card if there is one there? Sure. That is a _great_ source of noise if the card is properly set up. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-hackers Mon Oct 16 00:01:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA27853 for hackers-outgoing; Mon, 16 Oct 1995 00:01:14 -0700 Received: from dsw.com (root@gate.dsw.com [206.43.0.254]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA27848 for ; Mon, 16 Oct 1995 00:01:12 -0700 Received: from dsw.dsw.com by dsw.com (8.6.12) id BAA16444; Mon, 16 Oct 1995 01:01:10 -0600 Date: Mon, 16 Oct 1995 01:01:08 -0600 (MDT) From: Pete Kruckenberg To: hackers@freefall.freebsd.org, hardware@freebsd.org Subject: Re: Memory upgrade problems w/ 2.0.5R In-Reply-To: <199510151335.XAA04448@genesis.atrad.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sun, 15 Oct 1995, Michael Smith wrote: > Pete Kruckenberg stands accused of saying: > > modified my conf file with 'options MEMMAX="98304"', then rebuilt the > > kernel > > when building the kernel, I use optimizations (gcc 2.6.3): > > -O2 -m486 -fomit-frame-pointer -pipe > > -O2 is broken, and will result in bad code being generated. This is > possibly your problem. Well, at the suggestion of a couple of people, I'll rebuild a kernel using just -O for optimizations, and see how it goes. Thanks for your input. Pete Kruckenberg pete@dsw.com From owner-freebsd-hackers Mon Oct 16 00:07:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA27997 for hackers-outgoing; Mon, 16 Oct 1995 00:07:02 -0700 Received: from ns.easy.re.kr ([203.241.171.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA27992 for ; Mon, 16 Oct 1995 00:06:53 -0700 Received: (from moonhunt@localhost) by ns.easy.re.kr (8.6.12H1/8.6.9) id QAA03935 for freebsd-hackers@freebsd.org; Mon, 16 Oct 1995 16:06:07 +0900 Date: Mon, 16 Oct 1995 16:06:07 +0900 From: HyunSeog Ryu Message-Id: <199510160706.QAA03935@ns.easy.re.kr> To: freebsd-hackers@freebsd.org Subject: IO errors in multi-IO card by kernel Sender: owner-hackers@freebsd.org Precedence: bulk Dear everyone, I use P-75 machine with FreeBSD 2.0.5-950622-SNAP. I was installed multi-serial 4-port card to connect modem for BBS. It was runned correctly. But today it's kernel report some error message to console, and serial is not work. message is below. Oct 16 15:53:05 bbs /kernel: sio4: 1 more silo overflow(total 1) What's mean??? I was rebuild kernel by config & make. As to AST 4 port's method, it was runnung correctly... Please let me know this message's meaning... ;< Thank you for your reading. From Hyunseog Ryu =============================================================================== Name : Hyunseog Ryu moonhunt@easy.re.kr Tel : +82-2-884-0174 http://www.easy.re.kr/~moonhunt Fax : +82-2-884-0175 :-) EASY research institute Tomorrow is another day... ;> 4th floor, 304-25, shinrim 10-dong For better world, cheers!!! Kwanak-gu, Seoul, 151-020, Korea :-D =============================================================================== From owner-freebsd-hackers Mon Oct 16 01:10:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA29241 for hackers-outgoing; Mon, 16 Oct 1995 01:10:08 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA29234 for ; Mon, 16 Oct 1995 01:10:02 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA13025; Mon, 16 Oct 1995 09:09:44 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA15608; Mon, 16 Oct 1995 09:09:44 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA24180; Mon, 16 Oct 1995 08:30:59 +0100 From: J Wunsch Message-Id: <199510160730.IAA24180@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Mon, 16 Oct 1995 08:30:58 +0100 (MET) Cc: hackers@freefall.freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510160006.UAA06783@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 15, 95 08:06:30 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 882 Sender: owner-hackers@FreeBSD.org Precedence: bulk As Kaleb S. KEITHLEY wrote: > > >The > > extensive (i.e. blatant) use of message catalogs (AIX, IRIX) leads to > > very undesirable results, e.g. SMTP daemons throwing their error > > messages in German. :-( > > It's hard for me to know how something like smtpd would get its locale Ask IBM how they did it. :-) > set to de_DE in order to do that, but I wonder if that wouldn't be what > I'd want if I were in Germany. Seriously? So, please, drop a mail to foo@informatik.htw-dresden.de, and the tell me if the error message was really useful for you. Even better, find an AIX mailer in Japan, send a mail there, and... :) IMNSHO, daemons that are throwing messages to the outside world should not be localized. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Oct 16 01:10:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA29260 for hackers-outgoing; Mon, 16 Oct 1995 01:10:17 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA29240 for ; Mon, 16 Oct 1995 01:10:07 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA13064; Mon, 16 Oct 1995 09:10:01 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA15613; Mon, 16 Oct 1995 09:10:00 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA24201; Mon, 16 Oct 1995 08:37:42 +0100 From: J Wunsch Message-Id: <199510160737.IAA24201@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 16 Oct 1995 08:37:42 +0100 (MET) Cc: freebsd-hackers@freebsd.org (FreeBSD hackers) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510160111.KAA05393@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 16, 95 10:41:46 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1448 Sender: owner-hackers@freebsd.org Precedence: bulk As Michael Smith wrote: > > I'll second that 8) The AIX/OS2 etc standard of "(reference) message" > is still my favorite - the messages are usually verbose and at least vaguely > informative, and the numbers mean that when a luser is reading it to you > over the 'phone, that's all you need, coz you can look it up locally. > > (And thus it doesn't matter what language the message is in, because you > can regenerate it at will with the catalog lookup tool) The smtp error message is not intended for trained IBM personell that is good enough in Japanese to even understand the Japanese error messages :), it's intended for the _sender_ of the message. So unless IBM is in the belief that all the world is AIX trained personell (maybe they're really believing this, who knows? :-), this attitude is not very useful. Even for me, a mailer error message in German looks weird. I've only been picking their mailer daemon as an example i knew; i'm sure there are more hidden gotchas. SINIX systems (the Unix of a very minor German hardware vendor) prefer to ask you for "Anmeldename:" and "Kennwort:". Imagine the bunch of UUCP scripts that will stumple across this... :-) (Even though it's perhaps more useful than said SMTP errors. They are _never_ intended for a local user.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Oct 16 01:10:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA29292 for hackers-outgoing; Mon, 16 Oct 1995 01:10:37 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA29284 for ; Mon, 16 Oct 1995 01:10:32 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA13036 for ; Mon, 16 Oct 1995 09:09:58 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA15611 for freebsd-hackers@freebsd.org; Mon, 16 Oct 1995 09:09:57 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA24308 for freebsd-hackers@freebsd.org; Mon, 16 Oct 1995 08:44:08 +0100 From: J Wunsch Message-Id: <199510160744.IAA24308@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Mon, 16 Oct 1995 08:44:04 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 16, 95 02:49:36 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1049 Sender: owner-hackers@freebsd.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > >You misunderstood me. I was thinking of an explicit setlocale() > >inside all system utilities (except daemons) that use . > > 1) Too match sources will be changed cause troubles with patches > and upgrades. That doesn't count. The base utilities aren't being upgraded that often. > 2) It can be called twice, since first time call comes from > crt0. That should only result in a nop, does it? > 3) It is useful only for <=8bit locales, so you can't call setlocale, > multichars becomes damaged, you need to call reduced to 8bit > setlocale version as done in crt0. > 4) Using non-standard (non-POSIX/ANSI/etc) reduced setlocale in > all sources cause portability problems. Ah, i didn't knew that our locale support ain't complete yet. I was under the impression that the LC_CTYPE part was already ok. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Oct 16 01:11:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA29323 for hackers-outgoing; Mon, 16 Oct 1995 01:11:01 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA29316 for ; Mon, 16 Oct 1995 01:10:56 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA13107 for ; Mon, 16 Oct 1995 09:10:52 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA15622 for freebsd-hackers@freebsd.org; Mon, 16 Oct 1995 09:10:52 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id JAA24469 for freebsd-hackers@freebsd.org; Mon, 16 Oct 1995 09:00:34 +0100 From: J Wunsch Message-Id: <199510160800.JAA24469@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Mon, 16 Oct 1995 09:00:34 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 16, 95 05:45:55 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 358 Sender: owner-hackers@freebsd.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > So, I can't let European users live by price Russian/Japanese/etc. > users death. I thought Russia lies half in Europe, too? :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Oct 16 01:14:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA29540 for hackers-outgoing; Mon, 16 Oct 1995 01:14:29 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id BAA29535 for ; Mon, 16 Oct 1995 01:14:25 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t4kg3-0003vpC; Mon, 16 Oct 95 01:13 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id JAA00216; Mon, 16 Oct 1995 09:13:50 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: bde@zeta.org.au, j@uriah.heep.sax.de, hackers@freefall.freebsd.org, kaleb@x.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-reply-to: Your message of "Mon, 16 Oct 1995 08:43:10 +0300." Date: Mon, 16 Oct 1995 09:13:48 +0100 Message-ID: <214.813831228@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@FreeBSD.org Precedence: bulk > >Yes, bloat is added even when ENABLE_STARTUP_LOCALE isn't set. Bloat is > >added even when no ctype function is called (this is normal for most > >programs in /bin and /sbin - grep shows "ctype.h" in only 25 out of 80 > >programs in /usr/src/[s]bin. > > It isn't accurate results. Many libc functions calls ctype > indirecly, i.e. strtol, atoi, etc. You additionly need > to grep ctype through libc and then grep function you got > through bin/sbin. I suspect that 100% of programs use ctype > for accurate results. Andrey, you have to realize that Bruce reported precise numbers, whereas you just "suspect". Please prove you point, and provide hard numbers. > 1) I don't care of bloat on my proposal, I care of easy way of locale using. We've noticed already. > 2) We already discuss that bloat on early days and agree > let it be. No, we agreed to let it stay in crt0.s until it had been put the right place. crt0.s is NEVER the right place. > 3) I don't see proper way to avoid it for statically compiled > pgms, so I don't understand what we can discuss here. Yes > it isn't very good. Alternatives? Put it in the programs that need it. And only there. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. It will be some time yet before progress goes too far... (Poul Henningsen) From owner-freebsd-hackers Mon Oct 16 01:40:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA00318 for hackers-outgoing; Mon, 16 Oct 1995 01:40:08 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA00289 for ; Mon, 16 Oct 1995 01:39:54 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id KAA23449; Mon, 16 Oct 1995 10:39:40 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id KAA25610; Mon, 16 Oct 1995 10:39:39 +0200 Message-Id: <199510160839.KAA25610@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: Bruce Evans cc: hackers@FreeBSD.org Subject: Re: Creating a /dev/random Date: Mon, 16 Oct 1995 10:39:39 +0200 From: Mark Murray Sender: owner-hackers@FreeBSD.org Precedence: bulk > >I am building devices, /dev/random and /dev/urandom that when read give > >random noise generated in and by the kernel. So far it is going pretty > >well, but I have some unexplained hangs. I believe these are due to > >my complete lack of knowledge of what the uiomove() function is supposed > >to do. > > rbuf doesn't seem to be freed anywhere, so the malloc()s will eventually > consume all of kernel memory and then (at best) everything will hang in > malloc(). (Use ps inside db to see where things are hanging.) AHA! thanks for that! > To avoid this, use the existing buffer `zbuf', which is freed correctly. > There is no need for another variable - local variables are per process. > Perhaps `zbuf' should be renamed `buf'. > > Hmm, now I know why /dev/zero is so slow. The buffer is bzeroed for > every call. The buffer size is 4K, so reads of about 4K are about > twice as slow as they could by and reads of 1 byte are very slow > because 4K is bzeroed for each byte read. Reserving a page for the > zero buffer would be a bit wasteful and the copyout to move the data > is inelegant anyway. Perhaps there should be a zeroout() function to > optimize this important (;-) device. > > >+ poolsize = read_random(rbuf, CLBYTES); > >+ c = min(iov->iov_len, CLBYTES); > >+ c = min(c, poolsize); > >+ error = uiomove(rbuf, (int)c, uio); > > `c' should be calculated before calling rad_random() to avoid wasting > randomness. Huh? How? :-) Are you suggesting that there should be another call to return the number of bytes in the pool _before_ read_random is called? > The (int) cast suggests that there may be some type bogusness. Note that > c has type u_int, iov_len has type size_t and min() is only appropriate for > u_ints. Things work right only if size_t is u_int or iov_len is small. > poolsize and apparently read_random() have type int. read_random() had > better not return negative values for errors. Yup - this stinks. I'll fix it. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-hackers Mon Oct 16 01:49:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA00680 for hackers-outgoing; Mon, 16 Oct 1995 01:49:38 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA00643 for ; Mon, 16 Oct 1995 01:49:25 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id JAA28459 ; Mon, 16 Oct 1995 09:48:42 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id XAA23797 ; Sun, 15 Oct 1995 23:59:38 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id TAA03186; Fri, 13 Oct 1995 19:04:02 +0100 (MET) From: Ollivier Robert Message-Id: <199510131804.TAA03186@keltia.freenix.fr> Subject: Re: tcpdump: /dev/bpf0: Device not configured To: joerg_wunsch@uriah.heep.sax.de Date: Fri, 13 Oct 1995 19:04:01 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199510130721.IAA03327@uriah.heep.sax.de> from "J Wunsch" at Oct 13, 95 08:21:10 am X-Operating-System: FreeBSD 2.2-CURRENT ctm#1193 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG Precedence: bulk It seems that J Wunsch said: >>I really think KTRACE should be the default. Why one would not want KTRACE ? > > Because it's impact on speed? How much is it ? Has anyone tried to mesure it ? -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #2: Sat Oct 7 23:37:44 MET 1995 From owner-freebsd-hackers Mon Oct 16 02:05:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA01549 for hackers-outgoing; Mon, 16 Oct 1995 02:05:35 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA01537 for ; Mon, 16 Oct 1995 02:05:13 -0700 Received: by sequent.kiae.su id AA29890 (5.65.kiae-2 ); Mon, 16 Oct 1995 12:49:43 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 12:49:42 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id LAA02062; Mon, 16 Oct 1995 11:42:58 +0300 To: Poul-Henning Kamp Cc: bde@zeta.org.au, hackers@freefall.freebsd.org, j@uriah.heep.sax.de, kaleb@x.org References: <214.813831228@critter.tfs.com> In-Reply-To: <214.813831228@critter.tfs.com>; from Poul-Henning Kamp at Mon, 16 Oct 1995 09:13:48 +0100 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 11:42:58 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 43 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1890 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <214.813831228@critter.tfs.com> Poul-Henning Kamp writes: >> >Yes, bloat is added even when ENABLE_STARTUP_LOCALE isn't set. Bloat is >> >added even when no ctype function is called (this is normal for most >> >programs in /bin and /sbin - grep shows "ctype.h" in only 25 out of 80 >> >programs in /usr/src/[s]bin. >> >> It isn't accurate results. Many libc functions calls ctype >> indirecly, i.e. strtol, atoi, etc. You additionly need >> to grep ctype through libc and then grep function you got >> through bin/sbin. I suspect that 100% of programs use ctype >> for accurate results. >Andrey, you have to realize that Bruce reported precise numbers, whereas >you just "suspect". Please prove you point, and provide hard numbers. Ok, I'll do described steps by myself. >> 2) We already discuss that bloat on early days and agree >> let it be. >No, we agreed to let it stay in crt0.s until it had been put the right >place. crt0.s is NEVER the right place. I don't think so. >> 3) I don't see proper way to avoid it for statically compiled >> pgms, so I don't understand what we can discuss here. Yes >> it isn't very good. Alternatives? >Put it in the programs that need it. And only there. Do you really plan to convert all system and ports collection by inserting reduced setlocale call there? All ctype programs need it expect few ones which call setlocale by itself. I assume you something write/read with not pure english only. If so you can easily feel advantage of my method when all programs at one time fully understand your native language (ISO_8859-1 fits?). -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 02:17:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA02005 for hackers-outgoing; Mon, 16 Oct 1995 02:17:33 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA01993 for ; Mon, 16 Oct 1995 02:17:09 -0700 Received: by sequent.kiae.su id AA04114 (5.65.kiae-2 ); Mon, 16 Oct 1995 13:03:12 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 13:03:11 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id LAA02160; Mon, 16 Oct 1995 11:58:06 +0300 To: FreeBSD hackers , Joerg Wunsch References: <199510160800.JAA24469@uriah.heep.sax.de> In-Reply-To: <199510160800.JAA24469@uriah.heep.sax.de>; from J Wunsch at Mon, 16 Oct 1995 09:00:34 +0100 (MET) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 11:58:06 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 17 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 646 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510160800.JAA24469@uriah.heep.sax.de> J Wunsch writes: >As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: >> >> So, I can't let European users live by price Russian/Japanese/etc. >> users death. >I thought Russia lies half in Europe, too? :-) Well, when we found space in ISO8859-1 for all Russian chars, it will be true. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 02:31:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA02445 for hackers-outgoing; Mon, 16 Oct 1995 02:31:35 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA02429 for ; Mon, 16 Oct 1995 02:31:07 -0700 Received: by sovcom.kiae.su id AA07599 (5.65.kiae-1 ); Mon, 16 Oct 1995 12:25:05 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 12:25:05 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id MAA04804; Mon, 16 Oct 1995 12:23:36 +0300 To: Poul-Henning Kamp Cc: bde@zeta.org.au, hackers@freefall.freebsd.org, j@uriah.heep.sax.de, kaleb@x.org References: <214.813831228@critter.tfs.com> In-Reply-To: <214.813831228@critter.tfs.com>; from Poul-Henning Kamp at Mon, 16 Oct 1995 09:13:48 +0100 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 12:23:35 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 40 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1442 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <214.813831228@critter.tfs.com> Poul-Henning Kamp writes: >> >Yes, bloat is added even when ENABLE_STARTUP_LOCALE isn't set. Bloat is >> >added even when no ctype function is called (this is normal for most >> >programs in /bin and /sbin - grep shows "ctype.h" in only 25 out of 80 >> >programs in /usr/src/[s]bin. >> >> It isn't accurate results. Many libc functions calls ctype >> indirecly, i.e. strtol, atoi, etc. You additionly need >> to grep ctype through libc and then grep function you got >> through bin/sbin. I suspect that 100% of programs use ctype >> for accurate results. >Andrey, you have to realize that Bruce reported precise numbers, whereas >you just "suspect". Please prove you point, and provide hard numbers. Well, here more accurate results. I build/install special crt0.o version which not calls reduced_setlocale() bloat. Then I rebuild bin/sbin. Then I use following csh script to find ones which not use ctype at all: foreach i (*) nm $i/obj/$i | grep -l -q Locale || echo $i >> /tmp/result end running it on bin: 100% use ctype!!! running it on sbin: 100% use ctype!!! So my suspection was right. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 02:44:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA02711 for hackers-outgoing; Mon, 16 Oct 1995 02:44:27 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA02706 for ; Mon, 16 Oct 1995 02:43:59 -0700 Received: by sovcom.kiae.su id AA09528 (5.65.kiae-1 ); Mon, 16 Oct 1995 12:36:53 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 12:36:53 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id MAA04880; Mon, 16 Oct 1995 12:34:15 +0300 To: FreeBSD hackers , Joerg Wunsch References: <199510160744.IAA24308@uriah.heep.sax.de> In-Reply-To: <199510160744.IAA24308@uriah.heep.sax.de>; from J Wunsch at Mon, 16 Oct 1995 08:44:04 +0100 (MET) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 12:34:15 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 41 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1706 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message <199510160744.IAA24308@uriah.heep.sax.de> J Wunsch writes: >As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: >> >> >You misunderstood me. I was thinking of an explicit setlocale() >> >inside all system utilities (except daemons) that use . >> >> 1) Too match sources will be changed cause troubles with patches >> and upgrades. >That doesn't count. The base utilities aren't being upgraded that >often. And all ports utilities need to be upgraded too... >> 3) It is useful only for <=8bit locales, so you can't call setlocale, >> multichars becomes damaged, you need to call reduced to 8bit >> setlocale version as done in crt0. >> 4) Using non-standard (non-POSIX/ANSI/etc) reduced setlocale in >> all sources cause portability problems. >Ah, i didn't knew that our locale support ain't complete yet. I was >under the impression that the LC_CTYPE part was already ok. LC_CTYPE part _is_ already ok and because of it 'ls' with setlocale() from main() for Japanese LANG becomes broken right now. I repeat one again: 1) setlocale() is aware of multi-byte LANGs. 2) ls and other utilities not aware of multi-byte LANGs and becomes very broken because assumes that char type == char. 1) and 2) isn't purposes to not have correct ctype for ls if your charset is <= 8bit. My hack do it. For multi-byte LANGs ls and others stays to ASCII in my hack and don't becomes broken. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 03:31:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA04162 for hackers-outgoing; Mon, 16 Oct 1995 03:31:26 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id DAA04136 for ; Mon, 16 Oct 1995 03:30:49 -0700 Received: by sovcom.kiae.su id AA17403 (5.65.kiae-1 ); Mon, 16 Oct 1995 13:28:14 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 13:28:14 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id NAA05134; Mon, 16 Oct 1995 13:25:31 +0300 To: Poul-Henning Kamp Cc: bde@zeta.org.au, hackers@freefall.freebsd.org, j@uriah.heep.sax.de, kaleb@x.org References: <214.813831228@critter.tfs.com> In-Reply-To: ; from =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= at Mon, 16 Oct 1995 12:23:35 +0300 (MSK) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 13:25:31 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 52 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1909 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= writes: >In message <214.813831228@critter.tfs.com> Poul-Henning Kamp writes: >>> >Yes, bloat is added even when ENABLE_STARTUP_LOCALE isn't set. Bloat is >>> >added even when no ctype function is called (this is normal for most >>> >programs in /bin and /sbin - grep shows "ctype.h" in only 25 out of 80 >>> >programs in /usr/src/[s]bin. >>> >>> It isn't accurate results. Many libc functions calls ctype >>> indirecly, i.e. strtol, atoi, etc. You additionly need >>> to grep ctype through libc and then grep function you got >>> through bin/sbin. I suspect that 100% of programs use ctype >>> for accurate results. >>Andrey, you have to realize that Bruce reported precise numbers, whereas >>you just "suspect". Please prove you point, and provide hard numbers. >Well, here more accurate results. >I build/install special crt0.o version which not calls reduced_setlocale() >bloat. >Then I rebuild bin/sbin. Then I use following csh script to find ones >which not use ctype at all: >foreach i (*) >nm $i/obj/$i | grep -l -q Locale || echo $i >> /tmp/result >end >running it on bin: >100% use ctype!!! >running it on sbin: >100% use ctype!!! >So my suspection was right. It means that bloat reason is reduced_setlocale body itself. Purposes of reduced_setlocale is making _right_ ctype. Having right ctype is essential. Even Kaleb suggest to have right one (but right for 8859-1 only and broken for others and POSIX). My hack makes it right for any LANG value including 8859-1 and not violates POSIX. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 03:53:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA04651 for hackers-outgoing; Mon, 16 Oct 1995 03:53:24 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id DAA04646 for ; Mon, 16 Oct 1995 03:53:22 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t4n9Y-0003wOC; Mon, 16 Oct 95 03:52 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id LAA00415; Mon, 16 Oct 1995 11:52:30 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: bde@zeta.org.au, hackers@freefall.freebsd.org, j@uriah.heep.sax.de, kaleb@x.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-reply-to: Your message of "Mon, 16 Oct 1995 12:23:35 +0300." Date: Mon, 16 Oct 1995 11:52:29 +0100 Message-ID: <413.813840749@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@FreeBSD.org Precedence: bulk > In message <214.813831228@critter.tfs.com> Poul-Henning Kamp writes: > > >> >Yes, bloat is added even when ENABLE_STARTUP_LOCALE isn't set. Bloat is > >> >added even when no ctype function is called (this is normal for most > >> >programs in /bin and /sbin - grep shows "ctype.h" in only 25 out of 80 > >> >programs in /usr/src/[s]bin. > >> > >> It isn't accurate results. Many libc functions calls ctype > >> indirecly, i.e. strtol, atoi, etc. You additionly need > >> to grep ctype through libc and then grep function you got > >> through bin/sbin. I suspect that 100% of programs use ctype > >> for accurate results. > > >Andrey, you have to realize that Bruce reported precise numbers, whereas > >you just "suspect". Please prove you point, and provide hard numbers. > > Well, here more accurate results. > > I build/install special crt0.o version which not calls reduced_setlocale() > bloat. > Then I rebuild bin/sbin. Then I use following csh script to find ones > which not use ctype at all: Did you rebuild static or dynamic ? I will only belive numbers from a static rebuild... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. It will be some time yet before progress goes too far... (Poul Henningsen) From owner-freebsd-hackers Mon Oct 16 05:02:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA05977 for hackers-outgoing; Mon, 16 Oct 1995 05:02:30 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA05972 for ; Mon, 16 Oct 1995 05:02:23 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA25392; Mon, 16 Oct 1995 21:59:11 +1000 Date: Mon, 16 Oct 1995 21:59:11 +1000 From: Bruce Evans Message-Id: <199510161159.VAA25392@godzilla.zeta.org.au> To: bde@zeta.org.au, mark@grondar.za Subject: Re: Creating a /dev/random Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >> >+ poolsize = read_random(rbuf, CLBYTES); >> >+ c = min(iov->iov_len, CLBYTES); >> >+ c = min(c, poolsize); >> >+ error = uiomove(rbuf, (int)c, uio); >> >> `c' should be calculated before calling rad_random() to avoid wasting >> randomness. >Huh? How? :-) Are you suggesting that there should be another call to >return the number of bytes in the pool _before_ read_random is called? intc = imin(iov->iov_len, CLBYTES); poolsize = read_random(rbuf, intc); intc = imin(intc, poolsize); It the caller reads 1 byte at a time, then the original version throws away up to CLBYTES-1 bytes of randomness. Bruce From owner-freebsd-hackers Mon Oct 16 05:06:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA06082 for hackers-outgoing; Mon, 16 Oct 1995 05:06:20 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA06077 for ; Mon, 16 Oct 1995 05:05:51 -0700 Received: by sequent.kiae.su id AA28652 (5.65.kiae-2 ); Mon, 16 Oct 1995 15:51:02 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 15:51:02 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id OAA05471; Mon, 16 Oct 1995 14:46:56 +0300 To: Poul-Henning Kamp Cc: bde@zeta.org.au, hackers@freefall.freebsd.org, j@uriah.heep.sax.de, kaleb@x.org References: <413.813840749@critter.tfs.com> In-Reply-To: <413.813840749@critter.tfs.com>; from Poul-Henning Kamp at Mon, 16 Oct 1995 11:52:29 +0100 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 14:46:56 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 42 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1879 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <413.813840749@critter.tfs.com> Poul-Henning Kamp writes: >> In message <214.813831228@critter.tfs.com> Poul-Henning Kamp writes: >> >> >> >Yes, bloat is added even when ENABLE_STARTUP_LOCALE isn't set. Bloat is >> >> >added even when no ctype function is called (this is normal for most >> >> >programs in /bin and /sbin - grep shows "ctype.h" in only 25 out of 80 >> >> >programs in /usr/src/[s]bin. >> >> >> >> It isn't accurate results. Many libc functions calls ctype >> >> indirecly, i.e. strtol, atoi, etc. You additionly need >> >> to grep ctype through libc and then grep function you got >> >> through bin/sbin. I suspect that 100% of programs use ctype >> >> for accurate results. >> >> >Andrey, you have to realize that Bruce reported precise numbers, whereas >> >you just "suspect". Please prove you point, and provide hard numbers. >> >> Well, here more accurate results. >> >> I build/install special crt0.o version which not calls reduced_setlocale() >> bloat. >> Then I rebuild bin/sbin. Then I use following csh script to find ones >> which not use ctype at all: >Did you rebuild static or dynamic ? I will only belive numbers from a >static rebuild... I rebuild as default, i.e. static. You can repeat it by yourself, just comment out two lines into crt0.c and use my script after rebuild. Why you even assume that I can rebuild them as dynamic? Dynamic variant don't cause such bloat, so nobody count it. BTW, I don't give any 'numbers' here, I only prove that all our static programs _use_ ctype, so they needs _right_ ctype, i.e. my hack. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 05:34:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA06876 for hackers-outgoing; Mon, 16 Oct 1995 05:34:36 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA06870 for ; Mon, 16 Oct 1995 05:34:13 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id OAA23686; Mon, 16 Oct 1995 14:33:56 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id OAA26278; Mon, 16 Oct 1995 14:33:56 +0200 Message-Id: <199510161233.OAA26278@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: Bruce Evans cc: hackers@FreeBSD.org Subject: Re: Creating a /dev/random Date: Mon, 16 Oct 1995 14:33:55 +0200 From: Mark Murray Sender: owner-hackers@FreeBSD.org Precedence: bulk > >> >+ poolsize = read_random(rbuf, CLBYTES); > >> >+ c = min(iov->iov_len, CLBYTES); > >> >+ c = min(c, poolsize); > >> >+ error = uiomove(rbuf, (int)c, uio); > >> > >> `c' should be calculated before calling rad_random() to avoid wasting > >> randomness. > > >Huh? How? :-) Are you suggesting that there should be another call to > >return the number of bytes in the pool _before_ read_random is called? > > intc = imin(iov->iov_len, CLBYTES); > poolsize = read_random(rbuf, intc); > intc = imin(intc, poolsize); > > It the caller reads 1 byte at a time, then the original version throws > away up to CLBYTES-1 bytes of randomness. AHA! The undocumented internals of *iov... Thanks. I just learnt something useful here! M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-hackers Mon Oct 16 06:19:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA07691 for hackers-outgoing; Mon, 16 Oct 1995 06:19:50 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA07684 for ; Mon, 16 Oct 1995 06:19:45 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id XAA28075; Mon, 16 Oct 1995 23:16:52 +1000 Date: Mon, 16 Oct 1995 23:16:52 +1000 From: Bruce Evans Message-Id: <199510161316.XAA28075@godzilla.zeta.org.au> To: ache@astral.msk.su, bde@zeta.org.au, j@uriah.heep.sax.de Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Cc: hackers@freefall.freebsd.org, kaleb@x.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >>programs in /bin and /sbin - grep shows "ctype.h" in only 25 out of 80 >>programs in /usr/src/[s]bin. >It isn't accurate results. Many libc functions calls ctype >indirecly, i.e. strtol, atoi, etc. You additionly need >to grep ctype through libc and then grep function you got >through bin/sbin. I suspect that 100% of programs use ctype >for accurate results. strtoul etc. assume the C locale, not to mention the ASCII collating sequence for alpha characters. From strtoul.c: register unsigned char c; ... if (!isascii(c)) break; if (isdigit(c)) c -= '0'; else if (isalpha(c)) c -= isupper(c) ? 'A' - 10 : 'a' - 10; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ else break; if (c >= base) break; The man page says that the base must be <= 36, but this isn't checked for. The above would be less incorrect if it checked for c in the range [a-z] or [A-Z]. Then it would only be assuming an ASCII collating sequence and not the C locale. >>[bloat] >3) I don't see proper way to avoid it for statically compiled >pgms, so I don't understand what we can discuss here. Yes >it isn't very good. Alternatives? Perhaps something can be done using linker tricks. We need: if (ctype is really used (strtoul etc. don't count :-)) link to current _startup_setlocale else link to dummy _startup_setlocale Bruce From owner-freebsd-hackers Mon Oct 16 06:29:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA07904 for hackers-outgoing; Mon, 16 Oct 1995 06:29:48 -0700 Received: from fang.cs.sunyit.edu (fang.cs.sunyit.edu [192.52.220.66]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA07898 for ; Mon, 16 Oct 1995 06:29:45 -0700 Received: (from chuck@localhost) by fang.cs.sunyit.edu (8.6.9/8.6.9) id JAA18504 for hackers@freebsd.org; Mon, 16 Oct 1995 09:29:43 -0400 Date: Mon, 16 Oct 1995 09:29:43 -0400 From: Charles Kenneth Green - PRC Message-Id: <199510161329.JAA18504@fang.cs.sunyit.edu> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hackers@freebsd.org Subject: NetBSD/FreeBSD Sender: owner-hackers@freebsd.org Precedence: bulk Looking at the possibility of adding POSIX threads to FreeBSD, I found a group at MIT that has added POSIX threads to netbsd-1.0. I know that both systems have thier roots in the 4.4-lite distribution but just how much different are they now? Does this seem like a viable place to begin from in order to accomplish this task? -- Charles Green UN*X System Administration 22 Powell Ave. Apt. B UN*X Security & Whitesboro, NY 13492 Programming From owner-freebsd-hackers Mon Oct 16 06:43:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA08154 for hackers-outgoing; Mon, 16 Oct 1995 06:43:48 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA08145 for ; Mon, 16 Oct 1995 06:43:23 -0700 Received: by sovcom.kiae.su id AA19029 (5.65.kiae-1 ); Mon, 16 Oct 1995 16:34:14 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 16:34:14 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id QAA07072; Mon, 16 Oct 1995 16:32:25 +0300 To: bde@zeta.org.au, j@uriah.heep.sax.de Cc: hackers@freefall.freebsd.org, kaleb@x.org References: <199510161316.XAA28075@godzilla.zeta.org.au> In-Reply-To: <199510161316.XAA28075@godzilla.zeta.org.au>; from Bruce Evans at Mon, 16 Oct 1995 23:16:52 +1000 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 16:32:25 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 64 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2295 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510161316.XAA28075@godzilla.zeta.org.au> Bruce Evans writes: >>>programs in /bin and /sbin - grep shows "ctype.h" in only 25 out of 80 >>>programs in /usr/src/[s]bin. >>It isn't accurate results. Many libc functions calls ctype >>indirecly, i.e. strtol, atoi, etc. You additionly need >>to grep ctype through libc and then grep function you got >>through bin/sbin. I suspect that 100% of programs use ctype >>for accurate results. >strtoul etc. assume the C locale, not to mention the ASCII collating >sequence for alpha characters. From strtoul.c: > register unsigned char c; > ... > if (!isascii(c)) > break; > if (isdigit(c)) > c -= '0'; > else if (isalpha(c)) > c -= isupper(c) ? 'A' - 10 : 'a' - 10; > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > else > break; > if (c >= base) > break; >The man page says that the base must be <= 36, but this isn't checked for. >The above would be less incorrect if it checked for c in the range >[a-z] or [A-Z]. Then it would only be assuming an ASCII collating sequence >and not the C locale. Well, it is somewhat inaccurate again :-) Drums............ strtol uses isspace()!!! Even ISO8859-1 have additional space != ' ' (a0 if I remember right). CP866 have additional space too. Probably it doesn't play big role when number enters from terminal, but when some document parsed, it can easily contains various kinds of spaces. >>>[bloat] >>3) I don't see proper way to avoid it for statically compiled >>pgms, so I don't understand what we can discuss here. Yes >>it isn't very good. Alternatives? >Perhaps something can be done using linker tricks. We need: > if (ctype is really used (strtoul etc. don't count :-)) > link to current _startup_setlocale > else > link to dummy _startup_setlocale I agree with this proposal, but we need to count pure-ASCII ctype functions first before doing that. I suspect (I am not prove it yet :-) that pure-ASCII functions are rare thing. strtol isn't pure-ASCII f.e. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 06:49:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA08274 for hackers-outgoing; Mon, 16 Oct 1995 06:49:46 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA08268 for ; Mon, 16 Oct 1995 06:49:44 -0700 Received: from exalt.x.org by expo.x.org id AA17487; Mon, 16 Oct 95 09:46:52 -0400 Received: from localhost by exalt.x.org id JAA07333; Mon, 16 Oct 1995 09:46:46 -0400 Message-Id: <199510161346.JAA07333@exalt.x.org> To: hackers@freefall.FreeBSD.org Cc: Bruce Evans Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Mon, 16 Oct 1995 10:36:51 EST. <199510160036.KAA03511@godzilla.zeta.org.au> Organization: X Consortium Date: Mon, 16 Oct 1995 09:46:45 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk >>No, it doesn't need to be, but is there a reason it can't do the right >>thing anyway? The table is defined as having 256 elements, so populating >>it with something useful isn't going to hurt anything. >The C standard. E.g., in the "C" locale, islower() and isupper() are >specified as returning true only for the "C" lower and upper case letters. >Thus in the ASCII table, _L and _U must not be set for characters >= 128. Right you are. I could live with that restriction. -- Kaleb From owner-freebsd-hackers Mon Oct 16 06:53:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA08358 for hackers-outgoing; Mon, 16 Oct 1995 06:53:27 -0700 Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.125.68.130]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA08352 for ; Mon, 16 Oct 1995 06:52:56 -0700 Received: from elvisti.kiev.ua (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id PAA16494 for hackers@freebsd.org; Mon, 16 Oct 1995 15:54:04 +0200 Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.33]) by spider2.elvisti.kiev.ua (8.6.12/8.6.9) with ESMTP id PAA07791 for ; Mon, 16 Oct 1995 15:14:25 +0200 Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.6.9) id PAA21812 for hackers@freebsd.org; Mon, 16 Oct 1995 15:14:23 +0200 Date: Mon, 16 Oct 1995 15:14:23 +0200 From: "Andrew V. Stesin" Message-Id: <199510161314.PAA21812@office.elvisti.kiev.ua> To: hackers@freebsd.org Subject: Re: DOS Emulation under FreeBSD Organization: Electronni Visti InformAgency (ElVisti) X-Newsreader: TIN [version 1.2 PL2+] Sender: owner-hackers@freebsd.org Precedence: bulk Terry Lambert wrote: : It works on NetBSD, sorta. Someone implied it worked on FreeBSD. : It *should* work on FreeBSD. It works on 2.0.5R as advertised, the only problem we noticed here was some strangeness in "video RAM refresh". : Terry Lambert : terry@lambert.org : --- : Any opinions in this posting are my own and not those of my present : or previous employers. -- With best regards -- Andrew Stesin. +380 (44) 2760188 +380 (44) 2713457 +380 (44) 2713560 "...Good marketing beats good technology, every time". Pity. From owner-freebsd-hackers Mon Oct 16 07:15:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA08818 for hackers-outgoing; Mon, 16 Oct 1995 07:15:21 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA08807 for ; Mon, 16 Oct 1995 07:15:13 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA30026; Tue, 17 Oct 1995 00:08:44 +1000 Date: Tue, 17 Oct 1995 00:08:44 +1000 From: Bruce Evans Message-Id: <199510161408.AAA30026@godzilla.zeta.org.au> To: ache@astral.msk.su, phk@critter.tfs.com Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Cc: bde@zeta.org.au, hackers@freefall.freebsd.org, j@uriah.heep.sax.de, kaleb@x.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >running it on sbin: >100% use ctype!!! >So my suspection was right. This mainly proves that the library modules are even more excessively interdependent than at first appearance. I investigated why /sbin/dset references ctype: 1) dset references mkstemp() for some reason. mkstemp() uses only isdigit() from among the ctype functions. isdigit() isn't dependent on the locale, but it drags in locale stuff anyway. 2) dset references vfprintf() which references __dtoa(). __dtoa() doesn't reference ny ctype functions, but it is implemented in the same module as strtod() which does. strtod() references only isspace() among the ctype functions (it uses comparisons with '0' and '9' instead of isdigit()). Almost everything references printf so 2) applies to almost everything. Thus we have about 55 * 20K of bloat in [s]bin mainly for the stupid reason that a function that is almost never called (strtod()) needs to know what a space is. strtoul() etc. use isspace() too. They are used more often than strtod() and it's much more important that spaces work right than that bases > 36 work right, so ignore my previous mail saying that locales aren't important for strtoul() etc. Bruce From owner-freebsd-hackers Mon Oct 16 07:20:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA09032 for hackers-outgoing; Mon, 16 Oct 1995 07:20:35 -0700 Received: from ess.harris.com (su15a.ess.harris.com [130.41.1.251]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA09027 for ; Mon, 16 Oct 1995 07:20:32 -0700 Received: from borg.ess.harris.com (suw2k.ess.harris.com) by ess.harris.com (5.x/SMI-SVR4) id AA21639; Mon, 16 Oct 1995 10:20:24 -0400 Received: by borg.ess.harris.com (4.1/SMI-4.1) id AA28516; Mon, 16 Oct 95 10:17:38 EDT Date: Mon, 16 Oct 95 10:17:38 EDT From: jleppek@suw2k.ess.harris.com (James Leppek) Message-Id: <9510161417.AA28516@borg.ess.harris.com> To: hackers@freebsd.org, chuck@fang.cs.sunyit.edu Subject: Re: NetBSD/FreeBSD Sender: owner-hackers@freebsd.org Precedence: bulk the mit threads home page show that someone had done a freebsd port. There are config files for freebsd 1.1 and 2.0 :-) Jim Leppek > From owner-freebsd-hackers@freefall.freebsd.org Mon Oct 16 09:30:16 1995 > Date: Mon, 16 Oct 1995 09:29:43 -0400 > From: Charles Kenneth Green - PRC > X-Mailer: Mail User's Shell (7.2.5 10/14/92) > To: hackers@freebsd.org > Subject: NetBSD/FreeBSD > Sender: owner-hackers@freebsd.org > > Looking at the possibility of adding POSIX threads to FreeBSD, I > found a group at MIT that has added POSIX threads to netbsd-1.0. I know > that both systems have thier roots in the 4.4-lite distribution but just > how much different are they now? Does this seem like a viable place to > begin from in order to accomplish this task? > > > -- > Charles Green UN*X System Administration > 22 Powell Ave. Apt. B UN*X Security & > Whitesboro, NY 13492 Programming > From owner-freebsd-hackers Mon Oct 16 07:54:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA10203 for hackers-outgoing; Mon, 16 Oct 1995 07:54:17 -0700 Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.125.68.130]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA10189 for ; Mon, 16 Oct 1995 07:53:41 -0700 Received: from elvisti.kiev.ua (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id QAA19631 for hackers@freebsd.org; Mon, 16 Oct 1995 16:54:20 +0200 Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.33]) by spider2.elvisti.kiev.ua (8.6.12/8.6.9) with ESMTP id QAA23373 for ; Mon, 16 Oct 1995 16:29:02 +0200 Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.6.9) id QAA26398 for hackers@freebsd.org; Mon, 16 Oct 1995 16:29:01 +0200 Date: Mon, 16 Oct 1995 16:29:01 +0200 From: "Andrew V. Stesin" Message-Id: <199510161429.QAA26398@office.elvisti.kiev.ua> To: hackers@freebsd.org Subject: From BSDi mailing list on gcc-2.6.3 bugs: (fwd) A brief note about cc and gcc Organization: Electronni Visti InformAgency (ElVisti) Sender: owner-hackers@freebsd.org Precedence: bulk X-Inj-Env-From: ktts!devnull%havoc.techno.ru@crocodil.monolit.kiev.ua Sun Oct 15 11:17:29 1995 To: bsdi-users@bsdi.BSDI.COM Subject: A brief note about cc and gcc From: Chris Torek Date: Sat, 14 Oct 1995 19:49:29 -0600 In 2.0, `cc' gets you gcc 1.42 and `gcc' or `gcc2' gets you 2.6.3. Neither one of them is quite the same as the distribution version; in particular, I have installed at least a half dozen bug fixes in the 2.6.3 that we ship (including one that threw in a new bug, so that `gcc -pipe' does not always wait for the assembler to finish). I have not saved all of my test cases, but some sample bugs fixed: incorrect comparision of unsigned shorts incorrect loop jump optimization sign extension in library calls sign extension in switch (these all came from the FSF, were posted on the net, or were done here and sent back to the FSF, so should be in 2.7.0). The 1.42 version of gcc compiles much faster (about 3x; more if you are very short on physical memory, simply because the compiler is that much smaller) than version 2.6.3. The code is not quite as good, but many of the improvements in gcc 2.x are targeted towards RISC machines, and have less of an effect on the 386 architecture than on the SPARC, HP-PA, etc. We also disable by default some optimizations that work on machines with FPUs but not on machines without them. As others have mentioned before on this list, the reason is that our kernel does not emulate some complex instructions (such as FSIN and FCOS). The math library routines get the right answer, if a little slower. If you want to get the special instructions, use `-mfancy-math-387', and be sure you have a hardware FPU. -- In-Real-Life: Chris Torek, Berkeley Software Design Inc Berkeley, CA Domain: torek@bsdi.com +1 510 549 1145 -- With best regards -- Andrew Stesin. +380 (44) 2760188 +380 (44) 2713457 +380 (44) 2713560 "...Good marketing beats good technology, every time". Pity. From owner-freebsd-hackers Mon Oct 16 08:18:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA11118 for hackers-outgoing; Mon, 16 Oct 1995 08:18:58 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA11098 for ; Mon, 16 Oct 1995 08:18:40 -0700 Received: by sequent.kiae.su id AA09804 (5.65.kiae-2 ); Mon, 16 Oct 1995 19:08:54 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 19:08:54 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id SAA07637; Mon, 16 Oct 1995 18:06:04 +0300 To: Bruce Evans , phk@critter.tfs.com Cc: hackers@freefall.freebsd.org, j@uriah.heep.sax.de, kaleb@x.org References: <199510161408.AAA30026@godzilla.zeta.org.au> In-Reply-To: <199510161408.AAA30026@godzilla.zeta.org.au>; from Bruce Evans at Tue, 17 Oct 1995 00:08:44 +1000 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 18:06:04 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 42 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1730 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510161408.AAA30026@godzilla.zeta.org.au> Bruce Evans writes: >>running it on sbin: >>100% use ctype!!! >>So my suspection was right. >This mainly proves that the library modules are even more excessively >interdependent than at first appearance. I investigated why /sbin/dset >references ctype: >1) dset references mkstemp() for some reason. mkstemp() uses only > isdigit() from among the ctype functions. isdigit() isn't dependent > on the locale, but it drags in locale stuff anyway. Yes, mkstemp is one of rare functions which is pure-ASCII. I think direct test for '0' >= x =< '9' is preferred for pure-ASCII functions than ctype usage. >2) dset references vfprintf() which references __dtoa(). __dtoa() doesn't > reference ny ctype functions, but it is implemented in the same module > as strtod() which does. strtod() references only isspace() among the > ctype functions (it uses comparisons with '0' and '9' instead of > isdigit()). isspace() is purity killer. >Almost everything references printf so 2) applies to almost everything. >Thus we have about 55 * 20K of bloat in [s]bin mainly for the stupid >reason that a function that is almost never called (strtod()) needs to >know what a space is. vfprintf module calls too many functions besides dtoa, they are fflush, swsetup, sfvwrite, abort, etc. I am not shure that any of them not calls ctype functions indirectly additionly. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 08:23:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA11267 for hackers-outgoing; Mon, 16 Oct 1995 08:23:37 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA11261 for ; Mon, 16 Oct 1995 08:23:32 -0700 Received: from exalt.x.org by expo.x.org id AA20821; Mon, 16 Oct 95 11:23:00 -0400 Received: from localhost by exalt.x.org id LAA07456; Mon, 16 Oct 1995 11:22:54 -0400 Message-Id: <199510161522.LAA07456@exalt.x.org> To: ache@astral.msk.su Cc: hackers@freefall.FreeBSD.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Mon, 16 Oct 1995 04:13:55 EST. Organization: X Consortium Date: Mon, 16 Oct 1995 11:22:53 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk >>> >>BLANK fixes are incorrect, see isblank(3). >>> >>As I said, at least one system's docs claim it spec'd in ISO8859-1. I >>don't have an ISO8859-1 at hand, and I'm not even sure I have one at >>work, although I must, somewhere. >I don't need 8859-1 docs, I already have them. I need any isblank() >references. Maybe ANSI? 8859-1 is ISO. I would not expect ANSI or IEEE to address function behavior in a locale based on an ISO character encoding. What ANSI does say is that the behavior of is...() and to...() functions are implementation dependent when the locale is not "C". ANSI/POSIX/ISO C do not define isblank(), but do allow functions like it to be added. Now that I'm at work I can't find ISO8859-1. ISO8859-2 does not define what constitutes a blank, so I'll stick my neck out a little further than I already have and guess that ISO8859-1 does not either. When I say that SVR4 does not consider '\t' to be a blank I am not saying that FreeBSD should do the same merely because SVR4 does. What I am saying is: if you take iBSC seriously, then you should make isblank, in an ISO locale, work the same way that it would work on other systems. SunOS, Digital UNIX, and all various versions of SVR4 (Solaris 2,x, IRIX 5.x/6.x, NEWS-OS 6.x, and Unixware 2.x) all say '\t' is not blank. HPUX-10 and AIX-4 say it is, but they're not contenders for iBSC. Linux says it is too, and I would argue that Linux is broken for the same reason. I think we've made a mountain out of a molehill. -- Kaleb From owner-freebsd-hackers Mon Oct 16 08:32:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA11517 for hackers-outgoing; Mon, 16 Oct 1995 08:32:40 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA11510 for ; Mon, 16 Oct 1995 08:32:23 -0700 Received: by sequent.kiae.su id AA12448 (5.65.kiae-2 ); Mon, 16 Oct 1995 19:16:52 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 19:16:48 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id SAA07685; Mon, 16 Oct 1995 18:15:25 +0300 To: hackers@freefall.FreeBSD.org, "Kaleb S. KEITHLEY" References: <199510161425.KAA07364@exalt.x.org> In-Reply-To: <199510161425.KAA07364@exalt.x.org>; from "Kaleb S. KEITHLEY" at Mon, 16 Oct 1995 10:25:29 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 18:15:25 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 29 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1174 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510161425.KAA07364@exalt.x.org> Kaleb S. KEITHLEY writes: >>Preferring one particular charset >>among others leeds into various troubles. >Such as? I believe that providing a useful defaults is a good thing. >If you don't provide a useful default then it just compounds what >a programmer needs to do to write programs. The choice of a particular >default is usually driven by customer tastes and preferences. Such as breaking other charsets when default 8859-1 rules crossed with different current charset. ASCII rules can't be crossed with _any_ 8bit superset. >>I dislike X idea >>to have ISO8859-1 as default charset and think that they need >>to change it to ASCII. >Okay, I'll play. I claim that it is ASCII, and I challenge you to write >a program that proves otherwise. :-) Sorry, I forget that only left side is defined also 8859-1 name used. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 08:43:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA11953 for hackers-outgoing; Mon, 16 Oct 1995 08:43:50 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA11948 for ; Mon, 16 Oct 1995 08:43:45 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA00990; Tue, 17 Oct 1995 01:41:50 +1000 Date: Tue, 17 Oct 1995 01:41:50 +1000 From: Bruce Evans Message-Id: <199510161541.BAA00990@godzilla.zeta.org.au> To: ache@astral.msk.su, bde@zeta.org.au, phk@critter.tfs.com Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Cc: hackers@freefall.freebsd.org, j@uriah.heep.sax.de, kaleb@x.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >isspace() is purity killer. >>Almost everything references printf so 2) applies to almost everything. >>Thus we have about 55 * 20K of bloat in [s]bin mainly for the stupid >>reason that a function that is almost never called (strtod()) needs to >>know what a space is. >vfprintf module calls too many functions besides dtoa, they are >fflush, swsetup, sfvwrite, abort, etc. I am not shure that any of them >not calls ctype functions indirectly additionly. They don't. vfscanf() calls __dtoa() but is not used nearly as much as vfprintf(). Bruce From owner-freebsd-hackers Mon Oct 16 08:56:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA12323 for hackers-outgoing; Mon, 16 Oct 1995 08:56:03 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA12318 for ; Mon, 16 Oct 1995 08:55:58 -0700 Received: from exalt.x.org by expo.x.org id AA21966; Mon, 16 Oct 95 11:55:26 -0400 Received: from localhost by exalt.x.org id LAA07471; Mon, 16 Oct 1995 11:55:25 -0400 Message-Id: <199510161555.LAA07471@exalt.x.org> To: ache@astral.msk.su Cc: hackers@freefall.FreeBSD.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Mon, 16 Oct 1995 04:44:58 EST. Organization: X Consortium Date: Mon, 16 Oct 1995 11:55:24 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk >>>Bruce, I agree with you and POSIX agree with us. >>>Default table must be strict ASCII per POSIX. >>>So, we can close this table propogating subject. >>Does POSIX mention ASCII? ANSI allows other encodings >>of course, and is only strict for letters and digits, >>but only letters are very important. >Well 1003.1 says something about minimal subset to run C pgms. >Comparing ASCII and 8859-1 is clear that ASCII is more minimal. ANSI/POSIX/ISO C require that *at least* (my emphasis) A..Z, a..z, 0..9, !"#$&'()*+,-./:;<=>?[/]^_{~ , the space character, and control characters for horizontal tab, vertical tab, and form feed. For source files you must have a newline. For the execution environment the character set must also have control characters for alert, backspace, carriage return and new line. The only other restriction are on the decimal digits, 0..9, which must have a value one greater than the value of the previous. ASCII meets this criteria. ISO8859-1 also meets this criteria. There is not requirement that you use the most minimally compliant character set. I do not understand your insistence that the C locale be strictly ASCII and no more. I claim that it would be useful in the C locale if the default char- type table were to be nominally populated for 8859-1, i.e. excluding the upper and lower designations. You claim that doing so will break Russian and Japanese users. I claim that these users won't be using the C locale anyway. The fact that your locale support is broken and the utility programs are broken is merely an argument that they should be fixed. :-) -- Kaleb From owner-freebsd-hackers Mon Oct 16 09:00:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA12477 for hackers-outgoing; Mon, 16 Oct 1995 09:00:05 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA12452 for ; Mon, 16 Oct 1995 08:59:48 -0700 Received: by sequent.kiae.su id AA24837 (5.65.kiae-2 ); Mon, 16 Oct 1995 19:57:38 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 19:57:37 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id SAA07876; Mon, 16 Oct 1995 18:56:10 +0300 To: bde@zeta.org.au, phk@critter.tfs.com Cc: hackers@freefall.freebsd.org, j@uriah.heep.sax.de, kaleb@x.org References: <199510161541.BAA00990@godzilla.zeta.org.au> In-Reply-To: <199510161541.BAA00990@godzilla.zeta.org.au>; from Bruce Evans at Tue, 17 Oct 1995 01:41:50 +1000 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 18:56:09 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 29 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1225 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510161541.BAA00990@godzilla.zeta.org.au> Bruce Evans writes: >>isspace() is purity killer. >>>Almost everything references printf so 2) applies to almost everything. >>>Thus we have about 55 * 20K of bloat in [s]bin mainly for the stupid >>>reason that a function that is almost never called (strtod()) needs to >>>know what a space is. >>vfprintf module calls too many functions besides dtoa, they are >>fflush, swsetup, sfvwrite, abort, etc. I am not shure that any of them >>not calls ctype functions indirectly additionly. >They don't. vfscanf() calls __dtoa() but is not used nearly as much as >vfprintf(). Ok, it seems your idea to have two startup_locale stubs is useful. I think before implementing it we need to cleanup our libc (as well as other libraries too) to _not_ use ctype calls in pure-ASCII case and separate functions wich uses them from ones which not uses. It can takes much time... -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 09:03:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA12562 for hackers-outgoing; Mon, 16 Oct 1995 09:03:26 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA12533 for ; Mon, 16 Oct 1995 09:02:48 -0700 Received: by sequent.kiae.su id AA22556 (5.65.kiae-2 ); Mon, 16 Oct 1995 19:50:40 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 19:50:36 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id SAA07833; Mon, 16 Oct 1995 18:49:31 +0300 To: "Kaleb S. KEITHLEY" Cc: hackers@freefall.FreeBSD.org References: <199510161522.LAA07456@exalt.x.org> In-Reply-To: <199510161522.LAA07456@exalt.x.org>; from "Kaleb S. KEITHLEY" at Mon, 16 Oct 1995 11:22:53 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 18:49:31 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 27 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1260 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510161522.LAA07456@exalt.x.org> Kaleb S. KEITHLEY writes: >When I say that SVR4 does not consider '\t' to be a blank I am not >saying that FreeBSD should do the same merely because SVR4 does. What >I am saying is: if you take iBSC seriously, then you should make isblank, >in an ISO locale, work the same way that it would work on other systems. Well, it is a different approach. Since isblank() isn't syscall :-) IBCS2 stuff takes it from native SVR4 libc, BSD code not used here at all. >SunOS, Digital UNIX, and all various versions of SVR4 (Solaris 2,x, >IRIX 5.x/6.x, NEWS-OS 6.x, and Unixware 2.x) all say '\t' is not blank. >HPUX-10 and AIX-4 say it is, but they're not contenders for iBSC. Linux >says it is too, and I would argue that Linux is broken for the same >reason. So, if behavior is unclear and no docs exists, lets not change from one unclear behaviour to another but wait until some specifications comes on this subj. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 09:24:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA13248 for hackers-outgoing; Mon, 16 Oct 1995 09:24:38 -0700 Received: from k2.cs.dartmouth.edu (k2.cs.dartmouth.edu [129.170.200.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA13243 ; Mon, 16 Oct 1995 09:24:35 -0700 Received: by k2.cs.dartmouth.edu (8.6.12/4.2) id MAA04030; Mon, 16 Oct 1995 12:23:05 -0400 From: saurab@k2.cs.dartmouth.edu (Saurab Nog) Message-Id: <199510161623.MAA04030@k2.cs.dartmouth.edu> Subject: Portal File System To: freebsd-fs@freebsd.org, hackers@freebsd.org Date: Mon, 16 Oct 1995 12:23:03 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23beta2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 361 Sender: owner-hackers@freebsd.org Precedence: bulk Hi All, I am hoping to use the FreeBSD "Portal File System" for some research work that I am doing. I'm having problems getting started & haven't come across any documentation about how to use/program portals. I will be obliged if any of you could share past experience or pointers to useful stuff with me. Best Regards saurab (saurab@cs.dartmouth.edu) From owner-freebsd-hackers Mon Oct 16 09:33:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA13616 for hackers-outgoing; Mon, 16 Oct 1995 09:33:51 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA13608 for ; Mon, 16 Oct 1995 09:33:35 -0700 Received: by sequent.kiae.su id AA00618 (5.65.kiae-2 ); Mon, 16 Oct 1995 20:17:31 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 20:17:28 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id TAA07948; Mon, 16 Oct 1995 19:16:21 +0300 To: "Kaleb S. KEITHLEY" Cc: hackers@freefall.FreeBSD.org References: <199510161555.LAA07471@exalt.x.org> In-Reply-To: <199510161555.LAA07471@exalt.x.org>; from "Kaleb S. KEITHLEY" at Mon, 16 Oct 1995 11:55:24 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 19:16:21 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 50 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2017 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510161555.LAA07471@exalt.x.org> Kaleb S. KEITHLEY writes: >ASCII meets this criteria. ISO8859-1 also meets this criteria. There is >not requirement that you use the most minimally compliant character set. >I do not understand your insistence that the C locale be strictly ASCII >and no more. Well, do you see what POSIX work group means by "C" locale (attached at the end of the message?) >I claim that it would be useful in the C locale if the default char- >type table were to be nominally populated for 8859-1, i.e. excluding >the upper and lower designations. Just wondering, why you even need such damaged table... Some principles? :-) >You claim that doing so will break Russian and Japanese users. I claim >that these users won't be using the C locale anyway. The fact that your >locale support is broken and the utility programs are broken is merely >an argument that they should be fixed. :-) Sigh.... They == Russian/Japanese/Any users with charset != 8859-1, f.e. users with 8859-3. 1) They use _C_ locale for all not-setlocale-aware programs per POSIX: default behaviout is setlocale(LC_ALL, "C") at startup. 2) And they use _NATIVE_ locale for all setlocale-aware programs which calls setlocale(LC_ALL, "") f.e. in main(). Your propogating idea breaks case 1) (POSIX), i.e. breaks all not-setlocale-aware programs because 8859-1 rules mixed up with locale charset. I.e. 8859 treats native chars like they was 8859-1 chars. I cause that I see my native chars on the screen in strange places and I can even enter some of my native chars wich can cause unknown effects. Please, look more carefully on what I try to say (I try to say it in different ways already several times). -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 09:51:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA13915 for hackers-outgoing; Mon, 16 Oct 1995 09:51:15 -0700 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA13910 for ; Mon, 16 Oct 1995 09:51:12 -0700 Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA14267; Mon, 16 Oct 1995 12:50:39 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 16 Oct 1995 12:50 EDT Received: from lakes (lakes [192.96.3.39]) by ponds.UUCP (8.6.11/8.6.5) with ESMTP id JAA22190; Mon, 16 Oct 1995 09:13:45 -0400 Received: (from rivers@localhost) by lakes (8.6.11/8.6.9) id JAA02822; Mon, 16 Oct 1995 09:13:04 -0400 Date: Mon, 16 Oct 1995 09:13:04 -0400 From: Thomas David Rivers Message-Id: <199510161313.JAA02822@lakes> To: ache@astral.msk.su, x.org!kaleb@dg-rtp.dg.com Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Cc: hackers@freefall.FreeBSD.org Content-Type: text Content-Length: 777 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > Historycally ctype(>127) returns 0 in many systems that I see, > Well, being intimately involved with 'C' compilers and libraries on the mainframe (where EBCDIC, not ASCII rules the day) - I can tell you this is a problem... since the valid EBCDIC characters are negative if you have signed chars! Many valid EBCDIC characters have the high-bit set, making them much larger than 127. [I don't know how many customers pass negative values to ctype..] Fortunately, on those machines, 'char' is unsigned, but people still make mistakes with "portable" code. Also, we see a lot of people doing things like: if(ch < 127) { printf("%c\n", ch); } which doesn't work too well on an EBCDIC box. - Just to jump in from the other side of the world - - Dave Rivers - From owner-freebsd-hackers Mon Oct 16 09:51:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA13951 for hackers-outgoing; Mon, 16 Oct 1995 09:51:35 -0700 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA13928 for ; Mon, 16 Oct 1995 09:51:21 -0700 Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA14292; Mon, 16 Oct 1995 12:50:42 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 16 Oct 1995 12:50 EDT Received: from lakes (lakes [192.96.3.39]) by ponds.UUCP (8.6.11/8.6.5) with ESMTP id JAA22237; Mon, 16 Oct 1995 09:14:59 -0400 Received: (from rivers@localhost) by lakes (8.6.11/8.6.9) id JAA02829; Mon, 16 Oct 1995 09:14:20 -0400 Date: Mon, 16 Oct 1995 09:14:20 -0400 From: Thomas David Rivers Message-Id: <199510161314.JAA02829@lakes> To: ache@astral.msk.su, bde@zeta.org.au, zeta.org.au!bde@dg-rtp.dg.com, hackers@freefall.freebsd.org, kaleb@x.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Content-Type: text Content-Length: 504 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > >Bruce, I agree with you and POSIX agree with us. > >Default table must be strict ASCII per POSIX. > >So, we can close this table propogating subject. > > Does POSIX mention ASCII? ANSI allows other encodings > of course, and is only strict for letters and digits, > but only letters are very important. > > Bruce > POSIX explicitly does *not* mention ASCII. The OE/MVS POSIX system on the 370 mainframe (which is POSIX conforming according to IBM) is implemented in EBCDIC. - Dave Rivers - From owner-freebsd-hackers Mon Oct 16 10:25:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA14773 for hackers-outgoing; Mon, 16 Oct 1995 10:25:41 -0700 Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA14768 for ; Mon, 16 Oct 1995 10:25:22 -0700 Received: from curie.cs.tu-berlin.de (wosch@curie.cs.tu-berlin.de [130.149.18.44]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id SAA17707; Mon, 16 Oct 1995 18:24:27 +0100 From: Wolfram Schneider Received: (wosch@localhost) by curie.cs.tu-berlin.de (8.6.12/8.6.9) id SAA15762; Mon, 16 Oct 1995 18:24:21 +0100 Date: Mon, 16 Oct 1995 18:24:21 +0100 Message-Id: <199510161724.SAA15762@curie.cs.tu-berlin.de> To: "Kaleb S. KEITHLEY" Cc: hackers@freefall.FreeBSD.org Subject: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: <199510151053.GAA03600@exalt.x.org> References: <199510151053.GAA03600@exalt.x.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@FreeBSD.org Precedence: bulk Kaleb S. KEITHLEY writes: >Sorry if this shows up twice. The one I sent last night hasn't come >back yet, don't know if it got lost in the ether. > >1) > >% man -k rune >EUC(4) - EUC encoding of runes >UTF2(4) - Universal character set Transformation Format encoding of runes >mbrune(3), mbrrune(3), mbmb(3) - multibyte rune support for C >setrunelocale(3), setinvalidrune(3), sgetrune(3), sputrune(3) - rune support for C >%man setrunelocale >No manual entry for setrunelocale a) FreeBSD-{stable,current}/src/gnu/usr.bin/man/makewhatis/makewhatis.perl are differ, current/*/makewhatis say: setrunelocale(3), setinvalidrune(3), sgetrune(3), sputrune(3), rune(3) ^^^^ - rune support for C which give you a change to find the manpage. The real problem is that many manpages are bogus. E.g. try: $ manck -M /usr/share/man (manck is a package: sysutils/manck-1.0.tgz) Wolfram -- Wolfram Schneider wosch From owner-freebsd-hackers Mon Oct 16 10:32:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA14941 for hackers-outgoing; Mon, 16 Oct 1995 10:32:18 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA14936 for ; Mon, 16 Oct 1995 10:32:16 -0700 Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id KAA06722 for ; Mon, 16 Oct 1995 10:30:20 -0700 Received: from curie.cs.tu-berlin.de (wosch@curie.cs.tu-berlin.de [130.149.18.44]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id SAA17747 for ; Mon, 16 Oct 1995 18:25:44 +0100 From: Wolfram Schneider Received: (wosch@localhost) by curie.cs.tu-berlin.de (8.6.12/8.6.9) id SAA15767; Mon, 16 Oct 1995 18:25:42 +0100 Date: Mon, 16 Oct 1995 18:25:42 +0100 Message-Id: <199510161725.SAA15767@curie.cs.tu-berlin.de> To: hackers@freebsd.org Subject: FYI: Analysis of HTTP Performance problems MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org Precedence: bulk http://sunsite.unc.edu/mdma-release/http-prob.html Abstract This paper is the first in a series on performance issues in the World Wide Web. HTTP is a transfer protocol used by the World Wide Web distributed hypermedia system to retrieve distributed objects. HTTP uses TCP as a transport layer. Certain design features of HTTP interact badly with TCP, causing problems with performance and with server scalability. Latency problems are caused by opening a single connection per request, through connection setup and slow-start costs. Further avoidable latency is incurred due to the protocol only returning a single object per request. Scalability problems are caused by TCP requring a server to maintain state for all recently closed connections. Wolfram -- Wolfram Schneider wosch From owner-freebsd-hackers Mon Oct 16 11:37:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA16896 for hackers-outgoing; Mon, 16 Oct 1995 11:37:38 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA16865 ; Mon, 16 Oct 1995 11:37:25 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA25019; Mon, 16 Oct 1995 11:31:03 -0700 From: Terry Lambert Message-Id: <199510161831.LAA25019@phaeton.artisoft.com> Subject: Re: getdtablesize() broken? To: bakul@netcom.com (Bakul Shah) Date: Mon, 16 Oct 1995 11:31:02 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, hackers@freefall.freebsd.org, rdm@ic.net, current@freefall.freebsd.org In-Reply-To: <199510150649.XAA15664@netcom15.netcom.com> from "Bakul Shah" at Oct 14, 95 11:49:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3582 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > The correct limit on the largest number is FD_SETSIZE, as defined in > > sys/types.h. > > IMHO limiting the fdset bitarray size like this *within* the > kernel is a mistake. I have an application where I run into > this and am forced to use a multi process solution. Imagine > a server handling > FD_SETSIZE (i.e. 256) TCP connections > to clients -- requests are not all that frequent and each > takes just a little bit of time to service so they *can* all > be handled by one process easily. A multi process solution > gets complicated (need to put shared state in shared memory, > use locking etc.) and slower (extra contex switches, > lock/unlock time). > > Using a limit of FD_SETSIZE does not buy you extra > protection or anything. RLIMIT_NOFILE is the right limit to > check against in kern/sys_generic.c:select(). Mercifully > this limit is changeable via sysctl so server machines can > up it. NetBSD, FreeBSD, Linux and may be even bsdi (I > haven't checked recently) are all guilty here. Small upper > limits is another thing that separates PeeCees from serious > server machines. > > Let me say this another way. If I can create N files, I > should damn well be able to select() on any one of them. You should damn well be able to use fopen() instead of open() to get at them as well. Checked out the stdio libraries on every OS from FreeBSD to Solaris to VMS lately? Stdio has a hard limit, generally by use of a character to store the fd. The problem is the same as the "unlimited open FD's" problem: stupid programs like BASH that are too lazy to "chase their tail" on descriptor assignments are going to go to the top end and "work down" on the assumption that they can split the FD domain into two name space. Using FD_SETSIZE or using RLIMIT_NOFILE, or getting the current open descriptor limit from the kernel (when the application has an explicit bitvector element limitation set at compile time, not because of a check for FD_SETSIZE by because declaration of a bit vector uses the FD_SETSIZE to declare the vector length) is equally stupid and equally succeptible to screwups. The "correct" way is to get rid of the interfaces which are succeptible to bad programming style. The user *SHOULD* be using the highest open FD in the set of FD's being selected upon, *NOT* some arbitrary constant. Select's FD count should *NEVER* be coded as a constant. Poll, anyone? Poll is inferior to select, both because of the 10ms limit on timeout resoloution and because select is often used with no descriptors to get a timeout and poll can't be used in this mode. Arguably one would want to use this type of timeout mechanism in place of interval timers to get both interval timers and an I/O timeout at the same time. The correct thing to do for BASH is to push the open FD up by 10 or so each time a collision occurs and to maintain an internal mapping table so that the FD used for the script being executed moves out of the way of collisions cause be explicit descript references in the script itself. Similarly, the correct way to use select is to use the highest open descriptor as the highest open desciptor instead of some stupid arbitrary value (even if it does come from the kerne) and to min(FD_SETSIZE) and that value because if you don't, you are going to run off the end of the bit vector and SIGSEGV (best case) or if into mapped memory, you will potentially destroy data (worst case). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 11:55:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA17254 for hackers-outgoing; Mon, 16 Oct 1995 11:55:56 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA17249 for ; Mon, 16 Oct 1995 11:55:52 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA25106; Mon, 16 Oct 1995 11:50:13 -0700 From: Terry Lambert Message-Id: <199510161850.LAA25106@phaeton.artisoft.com> Subject: Re: IPX now available To: u923168@student.canberra.edu.au (Gasparovski / Daniel) Date: Mon, 16 Oct 1995 11:50:13 -0700 (MST) Cc: imp@village.org, hackers@FreeBSD.ORG In-Reply-To: from "Gasparovski / Daniel" at Oct 15, 95 05:09:22 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1117 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > : % bg >& make.out > > : [1]+ make world & > > : % > > : > > : Hurrah, the output is now redirected to make.out! > > > > I'd give half my left kidney for something like this! (Pure software > > already had my right kidney) > > Why can't this be done in the shell? Because credentials are associated with processes instead of being shared, seperate entities. It's grossly complicated why this is so, but that's what it boils down to. Once that is corrected, you'd still need the way the system deals with open vnode aliases repaired. Currently, if P1 opens a file and P2 opens a file, there are two entries in the system open file table pointing to a single vnode instead of a single entry with an incremented reference count. Without going multiply complex on the list linkage off the system open file table, that means going to iterating the process open file tables for things like identd and lsof. Very expensive, but relatively infrequent, so perhaps worth it. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 11:58:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA17334 for hackers-outgoing; Mon, 16 Oct 1995 11:58:22 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA17324 ; Mon, 16 Oct 1995 11:58:13 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA25115; Mon, 16 Oct 1995 11:53:20 -0700 From: Terry Lambert Message-Id: <199510161853.LAA25115@phaeton.artisoft.com> Subject: Re: lint To: bde@zeta.org.au (Bruce Evans) Date: Mon, 16 Oct 1995 11:53:20 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG, j@uriah.heep.sax.de, davidg@FreeBSD.ORG, dyson@FreeBSD.ORG In-Reply-To: <199510150952.TAA13687@godzilla.zeta.org.au> from "Bruce Evans" at Oct 15, 95 07:52:54 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 448 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > The 4.4lite2 style guide says to include only one of param.h and > types.h. In point of fact, all kernel code should probably include param.h. I made this mode locally because I had to have a global place to put a "#pragma packing" for a compiler I'm using to cross-compile FreeBSD for another platform. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 12:02:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA17468 for hackers-outgoing; Mon, 16 Oct 1995 12:02:46 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA17461 for ; Mon, 16 Oct 1995 12:02:31 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id VAA24005; Mon, 16 Oct 1995 21:02:14 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id VAA27145; Mon, 16 Oct 1995 21:02:13 +0200 Message-Id: <199510161902.VAA27145@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: Bruce Evans cc: hackers@FreeBSD.org Subject: Re: Creating a /dev/random Date: Mon, 16 Oct 1995 21:02:12 +0200 From: Mark Murray Sender: owner-hackers@FreeBSD.org Precedence: bulk > To avoid this, use the existing buffer `zbuf', which is freed correctly. > There is no need for another variable - local variables are per process. > Perhaps `zbuf' should be renamed `buf'. I don't understand something here - what happens if the one process is reading both /dev/zero and /dev/random? will the two not then try to share buf/zbuf and screw up? > Hmm, now I know why /dev/zero is so slow. The buffer is bzeroed for > every call. The buffer size is 4K, so reads of about 4K are about > twice as slow as they could by and reads of 1 byte are very slow > because 4K is bzeroed for each byte read. Reserving a page for the > zero buffer would be a bit wasteful and the copyout to move the data > is inelegant anyway. Perhaps there should be a zeroout() function to > optimize this important (;-) device. ...or only c bytes should be zero'ed out? M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-hackers Mon Oct 16 12:15:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA17832 for hackers-outgoing; Mon, 16 Oct 1995 12:15:29 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA17826 for ; Mon, 16 Oct 1995 12:15:26 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id MAA18887 for ; Mon, 16 Oct 1995 12:15:07 -0700 Message-Id: <199510161915.MAA18887@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: hackers@FreeBSD.org Subject: Speeding up last. Date: Mon, 16 Oct 1995 12:15:07 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.org Precedence: bulk Anyone looking for a good little "efficiency" project? Wolfram? :) Last takes a *tremendous* amount of CPU time to do what you would think is a simple task. Just try to use last on a busy ftp server and you will get an idea of the problem. Just counting the number of ftp logins in a 15 day old wtmp on wcarchive took 16 hours! (36MB wtmp file). David Greenman looked into the problem a bit and thinks that the strcmp() calls are the culprit... last does ~10 of them per entry. Even with 10 strcmps, it shouldn't take this long... -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Mon Oct 16 12:40:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA18378 for hackers-outgoing; Mon, 16 Oct 1995 12:40:08 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA18373 for ; Mon, 16 Oct 1995 12:40:05 -0700 Received: from exalt.x.org by expo.x.org id AA29388; Mon, 16 Oct 95 15:39:33 -0400 Received: from localhost by exalt.x.org id PAA08113; Mon, 16 Oct 1995 15:39:30 -0400 Message-Id: <199510161939.PAA08113@exalt.x.org> To: Terry Lambert Cc: hackers@freefall.FreeBSD.org Subject: Re: getdtablesize() broken? In-Reply-To: Your message of Mon, 16 Oct 1995 11:31:02 EST. <199510161831.LAA25019@phaeton.artisoft.com> Organization: X Consortium Date: Mon, 16 Oct 1995 15:39:29 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk >Poll, anyone? >Poll is inferior to select, Debatable. >both because of the 10ms limit on timeout >resoloution Man pages only say that if the host does not support millisecond accuracy then the value is rounded up to the nearest legal value available. >and because select is often used with no descriptors to >get a timeout and poll can't be used in this mode. That hasn't been my experience. poll(0, NULL, 10000); waits 10 seconds on SunOS, all SVR4-en I have here, HPUX, and AIX; however Digital Unix's poll looses. In fact in SVR4 select(3) is implemented using poll(2). In theory poll could be more efficient because there's less bit twiddling to do and unless you're polling thousands of files poll needs to transfer far less data to the kernel address space. Back in the days of 1.1.5.1 I started to look at what it would take to add poll. Maybe I'll look again. -- Kaleb From owner-freebsd-hackers Mon Oct 16 12:58:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA18670 for hackers-outgoing; Mon, 16 Oct 1995 12:58:59 -0700 Received: from fieber-john.campusview.indiana.edu (Fieber-John.campusview.indiana.edu [149.159.1.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA18665 for ; Mon, 16 Oct 1995 12:58:57 -0700 Received: (from jfieber@localhost) by fieber-john.campusview.indiana.edu (8.6.11/8.6.9) id OAA08682; Mon, 16 Oct 1995 14:58:32 -0500 Date: Mon, 16 Oct 1995 14:58:31 -0500 (EST) From: John Fieber To: "Amancio Hasty Jr." cc: freebsd mail , hackers@freefall.freebsd.org Subject: Re: Kodak Photo CD mount? In-Reply-To: <199510160037.RAA07006@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Sun, 15 Oct 1995, Amancio Hasty Jr. wrote: > > Please help! How do I mount a Koday photo CD? > > > > The drive is a: "TOSHIBA CD-ROM XM-3401TA 0283" type 5 removable SCSI 2 > > > I doubt that the "TOSHIBA CD-ROM XM-3401T" can understand PhotoCDs. The XM-3501 is perfectly happy with the few photocds I've tried. According the the cd-rom FAQ I have, the 3401 should handle single and multi-session photocds. -john == jfieber@indiana.edu =========================================== == http://fieber-john.campusview.indiana.edu/~jfieber ============ From owner-freebsd-hackers Mon Oct 16 13:08:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA19052 for hackers-outgoing; Mon, 16 Oct 1995 13:08:50 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA19047 ; Mon, 16 Oct 1995 13:08:44 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA25213; Mon, 16 Oct 1995 13:01:08 -0700 From: Terry Lambert Message-Id: <199510162001.NAA25213@phaeton.artisoft.com> Subject: Re: suggested changes to mbuf routines To: matt@lkg.dec.com (Matt Thomas) Date: Mon, 16 Oct 1995 13:01:07 -0700 (MST) Cc: julian@freefall.freebsd.org, hackers@freefall.freebsd.org In-Reply-To: <199510151123.LAA01923@whydos.lkg.dec.com> from "Matt Thomas" at Oct 15, 95 11:21:25 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1655 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > > In <199510141119.EAA05158@freefall.freebsd.org> , you wrote: > > I find the method of doing the references as done in Digital UNIX > (aka DEC OSF/1) quite clean. Basically the m_ext struct gets an > queue entry added. When the extended mbuf is first allocated, the > link queue entry merely points to itself (an empty queue). As more > references are made, their queues get linked together. As references > are removed, their queues get unlinked. > > To see if there is a non-zero reference count, imply see if the queue > entry points to itself. > > > /* description of external storage mapped into mbuf, valid if M_EXT set */ > struct m_ext { > caddr_t ext_buf; /* start of buffer */ > #if __STDC__ > void (*ext_free)(caddr_t, u_long, caddr_t); > #else > void (*ext_free)(); /* free routine if not the usual */ > #endif ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > u_int ext_size; /* size of buffer, for ext_free */ > caddr_t ext_arg; /* additional ext_free argument */ > struct ext_refq { /* reference list */ > struct ext_refq *forw, *back; > } ext_ref; > }; > > #define MCLREFERENCED(m) \ > ((m)->m_ext.ext_ref.forw != &((m)->m_ext.ext_ref)) This, I like. This: > void (*ext_free)(caddr_t, u_long, caddr_t); Should be: > void (*ext_free) __P((caddr_t, u_long, caddr_t)); Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 13:14:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA19224 for hackers-outgoing; Mon, 16 Oct 1995 13:14:28 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA19219 for ; Mon, 16 Oct 1995 13:14:21 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA25234; Mon, 16 Oct 1995 13:07:18 -0700 From: Terry Lambert Message-Id: <199510162007.NAA25234@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 13:07:18 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, hackers@freefall.freebsd.org, kaleb@x.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 15, 95 08:25:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1017 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >IMHO, the base utilities that use should properly initialize > >the locale instead of relying on that hack. (The hack is useful to > >force programs that don't like to handle locale's, but base utilities > >of the system are expected to do it right theirselves.) > > I have nothing against reverting this variable to > DISABLE_STARTUP_LOCALE f.e. If you remember I plan to make startup locale > as default for all program, but some peoples disagree, so I introduce > ENABLE_STARTUP_LOCALE. I also thing that the crt0 is the *wrong* place to do the locale work, which really belongs as a call in main(). It is wrong to "fix" broken use of a programming model by causing broken use of the startup model in it's place. Making this broken startup code implicit rather than explicit (by changing from a positive to a negative environment test) is just plain wrong. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 13:16:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA19271 for hackers-outgoing; Mon, 16 Oct 1995 13:16:27 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA19266 for ; Mon, 16 Oct 1995 13:16:21 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA25251; Mon, 16 Oct 1995 13:11:28 -0700 From: Terry Lambert Message-Id: <199510162011.NAA25251@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Mon, 16 Oct 1995 13:11:28 -0700 (MST) Cc: hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de In-Reply-To: <199510151805.OAA04841@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 15, 95 02:05:21 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1366 Sender: owner-hackers@FreeBSD.org Precedence: bulk > Yup, they could. It'd be a lot of work to go through every program and > add it. I could be way off base (great U.S./American colloquillism) but > my guess is that most programs probably don't need it unless you're also > going to make them use message catalogs at the same time, adding even > more work and probably compounding the issue of having a single boot > floppy and or loading in 4Meg. > > As near as I can tell the SVR4 ls doesn't change its locale, yet still > manages to do the right thing, probably because for most SVR4-en the C > locale is full ISO8859-1. This leads me to believe that FreeBSD's ls > probably doesn't need to change its locale either if the default chartype > table is fully populated. I greatly dislike the XPG3/XPG4 localization mechanisms, and have an even greater hate of per application message catalogs rather than shared message sets that are in fact system wide, with the occasional supplemental set for app specific stuff (consider that there are 5 common shells, mostly with common messages from the system error message list). I agree that the C locale should be 8859-1; an 8 bit clean locale would fix the majority of "problems" magically and without additional effort. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 13:21:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA19481 for hackers-outgoing; Mon, 16 Oct 1995 13:21:17 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA19476 for ; Mon, 16 Oct 1995 13:21:13 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA25265; Mon, 16 Oct 1995 13:15:22 -0700 From: Terry Lambert Message-Id: <199510162015.NAA25265@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: bde@zeta.org.au (Bruce Evans) Date: Mon, 16 Oct 1995 13:15:22 -0700 (MST) Cc: ache@astral.msk.su, j@uriah.heep.sax.de, hackers@freefall.freebsd.org, kaleb@x.org In-Reply-To: <199510152252.IAA32542@godzilla.zeta.org.au> from "Bruce Evans" at Oct 16, 95 08:52:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 661 Sender: owner-hackers@FreeBSD.org Precedence: bulk > BTW, this hack adds 24K to the size of a minimal statically linked > program `main() {}' and defeats the point of most of the specially named > routines in crt0.c. E.g., there is a special version of getenv() named > _getenv() to avoid the namespace pollution and bloat from getenv(), but > the hack calls getenv() anyway; there are special versions of read() and > write(), but _startup_setlocale() references things in stdio that reference > read() and write(). Can we say "probable source of BSDI incompatability"? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 13:40:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA20158 for hackers-outgoing; Mon, 16 Oct 1995 13:40:40 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA20150 for ; Mon, 16 Oct 1995 13:40:35 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA25305; Mon, 16 Oct 1995 13:34:10 -0700 From: Terry Lambert Message-Id: <199510162034.NAA25305@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 16 Oct 1995 13:34:10 -0700 (MST) Cc: kaleb@x.org, hackers@freefall.freebsd.org In-Reply-To: <199510152303.AAA22305@uriah.heep.sax.de> from "J Wunsch" at Oct 16, 95 00:03:59 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2786 Sender: owner-hackers@FreeBSD.org Precedence: bulk > As Kaleb S. KEITHLEY wrote: > > > > As near as I can tell the SVR4 ls doesn't change its locale, yet still > > manages to do the right thing, probably because for most SVR4-en the C > > locale is full ISO8859-1. This leads me to believe that FreeBSD's ls > > probably doesn't need to change its locale either if the default chartype > > table is fully populated. > > So SVR4 would still break on koi8-r, for example. Either make it > right, or let it be. But not on 8859-x. For Coptic alphabets, that's 8859-9. The problem with KOI-8 is that KOI-8 is a defacto standard, and is not accepted by international standards bodies. Mostly because the most popular BBS software in the area picked it up instead of 8859-9. The problem is not in the blank areas of the locale. In point of fact, the ANSI standards for terminal control sequences after ANSI 3.64 leave the codes in columns 0x80 and 0x90 to be used to represent 8 bit command sequence introducers, which are the same as an escape character followed by a character in columns 0x20 or 0x30. Because of this, KOI-8 as a character set is not compatible with post 3.64 ANSI terminal control sequence standardization. It is not unreasonable, then, for the code to function correctly in the 8-bit case for ISO 8859-x but not function correctly without an environment or (more preferrably) code change in the application for KOI-8. Really, they should be using the 8859 character set instead of KOI-8, but there is understood to be a large historical investment in the non-standard KOI-8 representation (unfortunately). > isctype() is not necessarily related to message catalogs. The > extensive (i.e. blatant) use of message catalogs (AIX, IRIX) leads to > very undesirable results, e.g. SMTP daemons throwing their error > messages in German. :-( This is an issue of when the message is translated: a function of the interface violation of an internationalized system. Actually, the error presentation between the dameons should be abstract and token based: ie: a number, which your smtp agen translates into the correct error. The problem is that the translation to a human representation should occur in the locale of the recipient of the human-form message rather than in the locale of the human who ran the program. That is, the error reporting protocol is a half-circuit and the abstraction is thereby compromised. The only correct procedure for dealing with this would be to change the error reporting in the SMTP protocol to encapsulate it as well as the transactions for which the error is being reported, and then translate it locally before presentation to the user. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 13:41:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA20241 for hackers-outgoing; Mon, 16 Oct 1995 13:41:34 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA20236 for ; Mon, 16 Oct 1995 13:41:31 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA25319; Mon, 16 Oct 1995 13:36:32 -0700 From: Terry Lambert Message-Id: <199510162036.NAA25319@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 13:36:32 -0700 (MST) Cc: hackers@freefall.freebsd.org, kaleb@x.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 16, 95 02:37:17 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 428 Sender: owner-hackers@FreeBSD.org Precedence: bulk > I don't have Posix specs near me right now, so anybody with Posix > please give more light on this subj. > We need to follow Posix regardles of manpage/program or SVR4 > currently does. The C locale should be 8859-1, then. If we take the POSIX definition of including the ANSI C spec. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 13:45:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA20440 for hackers-outgoing; Mon, 16 Oct 1995 13:45:07 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA20428 for ; Mon, 16 Oct 1995 13:45:00 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id QAA19270; Mon, 16 Oct 1995 16:58:01 -0400 Date: Mon, 16 Oct 1995 16:58:01 -0400 Message-Id: <199510162058.QAA19270@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hackers@freebsd.org From: dennis@etinc.com (dennis) Subject: 2.1 Release Cc: jkh@time.cdrom.com Sender: owner-hackers@freebsd.org Precedence: bulk Is there a release date for 2.1..that is..a date when it will be available on the net? It seems odd that there are 2.1 SNAPs but no release. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Mon Oct 16 13:46:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA20548 for hackers-outgoing; Mon, 16 Oct 1995 13:46:54 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA20542 for ; Mon, 16 Oct 1995 13:46:49 -0700 Received: by sequent.kiae.su id AA17567 (5.65.kiae-2 ); Tue, 17 Oct 1995 00:39:58 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 00:39:56 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id XAA00421; Mon, 16 Jan 1995 23:38:27 +0300 To: Terry Lambert Cc: hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, kaleb@x.org References: <199510162007.NAA25234@phaeton.artisoft.com> In-Reply-To: <199510162007.NAA25234@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 13:07:18 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Jan 1995 23:38:26 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 49 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2322 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510162007.NAA25234@phaeton.artisoft.com> Terry Lambert writes: >> >IMHO, the base utilities that use should properly initialize >> >the locale instead of relying on that hack. (The hack is useful to >> >force programs that don't like to handle locale's, but base utilities >> >of the system are expected to do it right theirselves.) >> >> I have nothing against reverting this variable to >> DISABLE_STARTUP_LOCALE f.e. If you remember I plan to make startup locale >> as default for all program, but some peoples disagree, so I introduce >> ENABLE_STARTUP_LOCALE. >I also thing that the crt0 is the *wrong* place to do the locale work, >which really belongs as a call in main(). It seems that every new person appears immediately starts to says the same wrong things as other starts instead of reading full discussion first where all this stuff already explained several times. It is very bad karma to call setlocale from main for ctype-oriented programs when chars size assumed <= 8bit. I already tries explain it to Joerg and if you really interested, you can found answer in my previous messages. Only crt0 is proper place for this things. >It is wrong to "fix" broken use of a programming model by causing >broken use of the startup model in it's place. >Making this broken startup code implicit rather than explicit (by changing >from a positive to a negative environment test) is just plain wrong. Well, what you consider as 'broken' most of user expect to see as 'i18n'. Why it is 'broken' to have right ctype at startup? Try to ask your customers, almost every user which directly sets "LANG" assume that 'ls' f.e. must be affected immediately and _not_ by additional hidden magic of 'setenv ENABLE_STARTUP_LOCALE'. If you don't want any startup code, simple not set your "LANG". Where was you when Kaleb suggest more uglier hack with default code table propogating? My hack keeps right ctype in all cases and his hack works only for 8859-1 and not works even for 8859-n, n != 1. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 13:46:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA20564 for hackers-outgoing; Mon, 16 Oct 1995 13:46:58 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA20547 for ; Mon, 16 Oct 1995 13:46:53 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA25331; Mon, 16 Oct 1995 13:40:10 -0700 From: Terry Lambert Message-Id: <199510162040.NAA25331@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 13:40:10 -0700 (MST) Cc: bde@zeta.org.au, j@uriah.heep.sax.de, hackers@freefall.freebsd.org, kaleb@x.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 16, 95 02:45:20 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1620 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >BTW, this hack adds 24K to the size of a minimal statically linked > >program `main() {}' and defeats the point of most of the specially named > >routines in crt0.c. E.g., there is a special version of getenv() named > >_getenv() to avoid the namespace pollution and bloat from getenv(), but > >the hack calls getenv() anyway; there are special versions of read() and > >write(), but _startup_setlocale() references things in stdio that reference > >read() and write(). > > And what? Now too many pgms require proper locale support, even ls, > so we can't avoid this thing. Code added regardles of > ENABLE_STARTUP_LOCALE set or not, so 'hack' means this variable > as I understand and not code added. As I already say, > I can revert default case to pick ctype and use variable > DISABLE_STARTUP_LOCALE to disable it for debugging purposes. aaaaaaaaaaaaaaauuuuuuuuuuuuuuuuuuuuuuuuuuggggggggggggggggggghhhhhhhhhhhhh! Why do we think ls requires this? Because the default locale is 'C', doesn't mean that the default locale should not be ISO 8 bit clean. Also, programs whose output is limited in this fashion should be explicitly calling setlocale(), or they are only half-assed in their attempt to support internationalization. In the case that it is explicitly called (ie: programs supposedly using these features), then the hack is unnecessary. Likewise, if the program is *not* using theses features, then they should stick their ugly noses into the tent uninvited. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 13:48:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA20622 for hackers-outgoing; Mon, 16 Oct 1995 13:48:08 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA20617 for ; Mon, 16 Oct 1995 13:48:02 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA25342; Mon, 16 Oct 1995 13:43:00 -0700 From: Terry Lambert Message-Id: <199510162043.NAA25342@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 13:43:00 -0700 (MST) Cc: hackers@freefall.freebsd.org, kaleb@x.org, joerg_wunsch@uriah.heep.sax.de In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 16, 95 03:31:11 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 403 Sender: owner-hackers@FreeBSD.org Precedence: bulk > What you mean by majority? Russian users amount is comparable > with all european users, why not extend default table to KOI8-R > instead? Because post ANSI 3.64 terminal control codes reserve 0x80..0x9f and KOI8-R does not respect this international standard? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 13:56:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA20915 for hackers-outgoing; Mon, 16 Oct 1995 13:56:33 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA20908 for ; Mon, 16 Oct 1995 13:56:19 -0700 Received: by sovcom.kiae.su id AA13453 (5.65.kiae-1 ); Mon, 16 Oct 1995 23:46:59 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 23:46:58 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id XAA00488; Mon, 16 Jan 1995 23:45:07 +0300 To: Bruce Evans , Terry Lambert Cc: hackers@freefall.freebsd.org, j@uriah.heep.sax.de, kaleb@x.org References: <199510162015.NAA25265@phaeton.artisoft.com> In-Reply-To: <199510162015.NAA25265@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 13:15:22 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Jan 1995 23:45:07 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 20 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 981 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510162015.NAA25265@phaeton.artisoft.com> Terry Lambert writes: >> BTW, this hack adds 24K to the size of a minimal statically linked >> program `main() {}' and defeats the point of most of the specially named >> routines in crt0.c. E.g., there is a special version of getenv() named >> _getenv() to avoid the namespace pollution and bloat from getenv(), but >> the hack calls getenv() anyway; there are special versions of read() and >> write(), but _startup_setlocale() references things in stdio that reference >> read() and write(). >Can we say "probable source of BSDI incompatability"? What? Are you joking? Maybe source of IBM mainframe incompatibility too? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 14:00:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA21039 for hackers-outgoing; Mon, 16 Oct 1995 14:00:51 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA21031 for ; Mon, 16 Oct 1995 14:00:44 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA25380; Mon, 16 Oct 1995 13:55:52 -0700 From: Terry Lambert Message-Id: <199510162055.NAA25380@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Mon, 16 Oct 1995 13:55:52 -0700 (MST) Cc: hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de In-Reply-To: <199510160006.UAA06783@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 15, 95 08:06:30 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3961 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > So SVR4 would still break on koi8-r, for example. > > No it wouldn't because SVR4 doesn't have a koi8-r locale. If it has > anything it probably is based on ISO8859-5, which, if I'm not mistaken, > uses ASCII on the left side and Cyrillic on the right side; thus a multi- > byte string like a file name might look different in one locale than in > another. isn't -9 Cyrillic? I think -5 is Greek? If I have these reversed, change -9 to -5 in my pervious posts re: Coptic/Cyrillic. > The only way to *really* solve this is to do something like use widechar > strings in the file system and declare that all filenames are encoded > in something like Unicode. Unless I misunderstood him, this is what Terry > Lambert was lobbying for a couple of weeks ago, when he was asking for > 16-bit wchar_t. This has all kinds of implications, but let's not go down > that rathole right now. :-) It's not really a rathole. I has it running in November of 1993. But yes, that's *exactly* what and why I was lobbying. > > Either make it right, or let it be. > > Define right! I don't see it as wrong to populate the right half of the > default chartype table with values that are useful in some particular > locale -- in this case "C". No more wrong than leaving them blank. It > is merely a convenience simple programs be able to do something useful > for the majority of the users. Is the customer always right? If a > particular tool isn't very useful in the general case, a customer might > choose another another tool that is, in the general case, more useful. Actually, I believe the ISO refomalization of the ANSI C standard defines 'C' as the default locale, and allows all characters not in 0x00-0x1f and 0x80-0x9f to be passed through unaltered. Personally, I hate XPG3/XPG4 locale support. If you must do it wrong, I'd suggest ISO2022. My personal preference is the allocated code pages of ISO10646 (in other words, 16 bit Unicode). > > isctype() is not necessarily related to message catalogs. > > ??? I didn't say it was. I said that changing programs to set the locale > was not very interesting (or necessary) unless you were going to make > them use message catalogs for their output. I agree. The use of an isctype table that does not follow the ISO conventions for 8859-x fonts may be ANSI compliant, but it is *NOT* ISO compliant. And once compliance is there, it's only odd-ball character sets which illegally use 0x80-0x9f as printed characters in violation of 3.64 (which is also formalized by ISO) and ASN.1 that will have problems with non internationalized code that doesn't call setlocale() properly. And the right way to correct that is to use an international standard 8859-x set instead of the "defacto standard" KOI-8. Or convert the programs. Don't put crap in crt0.o, or if you *do* put crap there, damn well don't turn it on and "crappify" everything by default. > > very undesirable results, e.g. SMTP daemons throwing their error > > messages in German. :-( > > It's hard for me to know how something like smtpd would get its locale > set to de_DE in order to do that, but I wonder if that wouldn't be what > I'd want if I were in Germany. It would be running in the German locale on a german machine and send back "no such user" errors to you in German. The correct way to fix this is to encapsulate error representation so that the encapsulated form is translated into the locale specific form by the agent for the user recieving the error. This is *precisely* why XPG3/XPG4 message catalog formalization sucks out, since it does nothing to define a cannonical form other than that of the string in the source code prior to abstraction, and so the ID for the message could vary from version to version, and each program would have to have it's own catalogs. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 14:14:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA21520 for hackers-outgoing; Mon, 16 Oct 1995 14:14:05 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA21511 for ; Mon, 16 Oct 1995 14:13:56 -0700 Received: by sovcom.kiae.su id AA15034 (5.65.kiae-1 ); Tue, 17 Oct 1995 00:02:34 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 00:02:34 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id XAA00543; Mon, 16 Jan 1995 23:53:17 +0300 To: Terry Lambert Cc: hackers@freefall.freebsd.org, kaleb@x.org References: <199510162036.NAA25319@phaeton.artisoft.com> In-Reply-To: <199510162036.NAA25319@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 13:36:32 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Jan 1995 23:53:17 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 18 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 733 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510162036.NAA25319@phaeton.artisoft.com> Terry Lambert writes: >> I don't have Posix specs near me right now, so anybody with Posix >> please give more light on this subj. >> We need to follow Posix regardles of manpage/program or SVR4 >> currently does. >The C locale should be 8859-1, then. If we take the POSIX definition >of including the ANSI C spec. Where you found _exactly_ that C locale should be 8859-1??? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 14:15:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA21567 for hackers-outgoing; Mon, 16 Oct 1995 14:15:01 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA21547 for ; Mon, 16 Oct 1995 14:14:46 -0700 Received: by sovcom.kiae.su id AA15032 (5.65.kiae-1 ); Tue, 17 Oct 1995 00:02:33 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 00:02:33 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id XAA00536; Mon, 16 Jan 1995 23:52:13 +0300 To: Terry Lambert Cc: hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, kaleb@x.org References: <199510162043.NAA25342@phaeton.artisoft.com> In-Reply-To: <199510162043.NAA25342@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 13:43:00 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Jan 1995 23:52:13 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 19 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 788 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510162043.NAA25342@phaeton.artisoft.com> Terry Lambert writes: >> What you mean by majority? Russian users amount is comparable >> with all european users, why not extend default table to KOI8-R >> instead? >Because post ANSI 3.64 terminal control codes reserve 0x80..0x9f and >KOI8-R does not respect this international standard? KOI8-R leters started from 0xA3. All other chars treated as supplimentary. 0x80..0x9f range have most less used chars which may be ommited. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 14:16:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA21638 for hackers-outgoing; Mon, 16 Oct 1995 14:16:15 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA21624 for ; Mon, 16 Oct 1995 14:15:59 -0700 Received: by sequent.kiae.su id AA00648 (5.65.kiae-2 ); Tue, 17 Oct 1995 01:15:07 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 01:15:07 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id AAA00617; Tue, 17 Jan 1995 00:10:14 +0300 To: joerg_wunsch@uriah.heep.sax.de, Terry Lambert Cc: hackers@freefall.freebsd.org, kaleb@x.org References: <199510162034.NAA25305@phaeton.artisoft.com> In-Reply-To: <199510162034.NAA25305@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 13:34:10 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Jan 1995 00:10:13 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 61 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2524 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510162034.NAA25305@phaeton.artisoft.com> Terry Lambert writes: >> As Kaleb S. KEITHLEY wrote: >> > >> > As near as I can tell the SVR4 ls doesn't change its locale, yet still >> > manages to do the right thing, probably because for most SVR4-en the C >> > locale is full ISO8859-1. This leads me to believe that FreeBSD's ls >> > probably doesn't need to change its locale either if the default chartype >> > table is fully populated. >> >> So SVR4 would still break on koi8-r, for example. Either make it >> right, or let it be. >But not on 8859-x. For Coptic alphabets, that's 8859-9. SVR4/Kaleb solution breaks any charset which != 8859-1. >The problem with KOI-8 is that KOI-8 is a defacto standard, and is not >accepted by international standards bodies. Mostly because the most It accepted by IANA, see RFC 1700. >popular BBS software in the area picked it up instead of 8859-9. BSD software in the area uses CP866. >The problem is not in the blank areas of the locale. Why you even decide that problem is in the blank area? >In point of fact, the ANSI standards for terminal control sequences >after ANSI 3.64 leave the codes in columns 0x80 and 0x90 to be used >to represent 8 bit command sequence introducers, which are the same >as an escape character followed by a character in columns 0x20 or 0x30. >Because of this, KOI-8 as a character set is not compatible with post >3.64 ANSI terminal control sequence standardization. When KOI8-R code table was designed, it was keeped in mind, so 0x80 range cotains less used chars which can be safely ommited. >It is not unreasonable, then, for the code to function correctly in >the 8-bit case for ISO 8859-x but not function correctly without an >environment or (more preferrably) code change in the application for >KOI-8. Even 8859-2 becomes broken when C locale becomes 8859-1. Read full discussion before answering. >Really, they should be using the 8859 character set instead of KOI-8, >but there is understood to be a large historical investment in the >non-standard KOI-8 representation (unfortunately). 8859-5 us deadborn. Nobody use it currently. It was designed by foreigners for russians, such attempts are always deadborn. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 14:17:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA21716 for hackers-outgoing; Mon, 16 Oct 1995 14:17:37 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA21710 for ; Mon, 16 Oct 1995 14:17:18 -0700 Received: by sovcom.kiae.su id AA15036 (5.65.kiae-1 ); Tue, 17 Oct 1995 00:02:34 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 00:02:34 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id AAA00567; Tue, 17 Jan 1995 00:00:12 +0300 To: Terry Lambert Cc: bde@zeta.org.au, hackers@freefall.freebsd.org, j@uriah.heep.sax.de, kaleb@x.org References: <199510162040.NAA25331@phaeton.artisoft.com> In-Reply-To: <199510162040.NAA25331@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 13:40:10 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Jan 1995 00:00:12 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 58 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2465 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510162040.NAA25331@phaeton.artisoft.com> Terry Lambert writes: >> >BTW, this hack adds 24K to the size of a minimal statically linked >> >program `main() {}' and defeats the point of most of the specially named >> >routines in crt0.c. E.g., there is a special version of getenv() named >> >_getenv() to avoid the namespace pollution and bloat from getenv(), but >> >the hack calls getenv() anyway; there are special versions of read() and >> >write(), but _startup_setlocale() references things in stdio that reference >> >read() and write(). >> >> And what? Now too many pgms require proper locale support, even ls, >> so we can't avoid this thing. Code added regardles of >> ENABLE_STARTUP_LOCALE set or not, so 'hack' means this variable >> as I understand and not code added. As I already say, >> I can revert default case to pick ctype and use variable >> DISABLE_STARTUP_LOCALE to disable it for debugging purposes. >aaaaaaaaaaaaaaauuuuuuuuuuuuuuuuuuuuuuuuuuggggggggggggggggggghhhhhhhhhhhhh! >Why do we think ls requires this? It is simple: to display native filenames. >Because the default locale is 'C', doesn't mean that the default locale >should not be ISO 8 bit clean. It is already 8bit clean. You can safely call ctype(>127). >Also, programs whose output is limited in this fashion should be >explicitly calling setlocale(), or they are only half-assed in their >attempt to support internationalization. Correct ctype != half-assed. Correct ctype != full i18n Correct ctype is what user expects at least. Majority of users use various 8bit charsets and >8bit charsets isn't commonly used. Why not make life easier for all 8bit charsets users, if this not affects at all >8bit users? >In the case that it is explicitly called (ie: programs supposedly using >these features), then the hack is unnecessary. And what? Second call does no-op. >Likewise, if the program is *not* using theses features, then they >should stick their ugly noses into the tent uninvited. Users prefers to interact in native language with all programs which they have. It is hard to explain to user why tcsh reacts on LANG settings when ls does not. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 14:42:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA23146 for hackers-outgoing; Mon, 16 Oct 1995 14:42:54 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA23139 for ; Mon, 16 Oct 1995 14:42:49 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA25492; Mon, 16 Oct 1995 14:37:18 -0700 From: Terry Lambert Message-Id: <199510162137.OAA25492@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 14:37:18 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, hackers@freefall.freebsd.org, j@uriah.heep.sax.de, kaleb@x.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Jan 17, 95 00:00:12 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3330 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >> And what? Now too many pgms require proper locale support, even ls, > >> so we can't avoid this thing. Code added regardles of > >> ENABLE_STARTUP_LOCALE set or not, so 'hack' means this variable > >> as I understand and not code added. As I already say, > >> I can revert default case to pick ctype and use variable > >> DISABLE_STARTUP_LOCALE to disable it for debugging purposes. > > >aaaaaaaaaaaaaaauuuuuuuuuuuuuuuuuuuuuuuuuuggggggggggggggggggghhhhhhhhhhhhh! > > >Why do we think ls requires this? > > It is simple: to display native filenames. Excuse me. All you need is the correct matching keyboard/font, an 8 bit clean code path (which the current limited C locale and automatically calling setlocale() in ctr0.o screws up), and the guarantee that your character encodings don't stomp on control sequence reserved areas, like 0x00-0x1f,0x80-0x9f. Except for the bogus C locale (which I agree is bogus), and the fact that KOI-8 disrepectfully stomps on control areas with its data, you already have all that. To get around the stomping, you'll have to define a locale and make the programs locale aware. Or get an encoding standard that respects 8859-x and ISO control encoding. > >Because the default locale is 'C', doesn't mean that the default locale > >should not be ISO 8 bit clean. > > It is already 8bit clean. You can safely call ctype(>127). Excuse me. The C locale does not return the same values as 8859-1. It is not ISO 8 bit encoding clean. > >Also, programs whose output is limited in this fashion should be > >explicitly calling setlocale(), or they are only half-assed in their > >attempt to support internationalization. > > Correct ctype != half-assed. > Correct ctype != full i18n > Correct ctype is what user expects at least. Read the ISO standization of the ANSI C standard with respect to the C locale. The specific wording is "is undefined". You can make it return whatever you want it to for that. Including i18n. > Majority of users use various 8bit charsets and >8bit charsets > isn't commonly used. Why not make life easier for all 8bit charsets > users, if this not affects at all >8bit users? Exactly. Define the undefined portions of the C locale to act in an implementation dependent fashion. That happens to look exactly like 8859-1. > >In the case that it is explicitly called (ie: programs supposedly using > >these features), then the hack is unnecessary. > > And what? Second call does no-op. First call should not be made at all in a non-internationalized program; the default behaviour should be i18n. > >Likewise, if the program is *not* using theses features, then they > >should stick their ugly noses into the tent uninvited. > > Users prefers to interact in native language with all programs > which they have. It is hard to explain to user why tcsh reacts > on LANG settings when ls does not. Neither one should react, or at least the characters displayed should not change. The conversion of the high bit set characters into '?' in ls is broken. When a character in the 0x20-0x7f,0xa0-0xff range is put out, it should not be translated or otherwise multilated if you are in a C or i18n locale. Period. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 14:43:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA23187 for hackers-outgoing; Mon, 16 Oct 1995 14:43:53 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA23182 for ; Mon, 16 Oct 1995 14:43:49 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA25508; Mon, 16 Oct 1995 14:38:38 -0700 From: Terry Lambert Message-Id: <199510162138.OAA25508@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 14:38:38 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.freebsd.org, kaleb@x.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Jan 16, 95 11:53:17 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 670 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >> I don't have Posix specs near me right now, so anybody with Posix > >> please give more light on this subj. > >> We need to follow Posix regardles of manpage/program or SVR4 > >> currently does. > > >The C locale should be 8859-1, then. If we take the POSIX definition > >of including the ANSI C spec. > > Where you found _exactly_ that C locale should be 8859-1??? 1) ISO formailzation of ANSI C standard say "is undefined". 2) I choose 8859-1 behaviour as the "undefined" behaviour I coose to get in my implementation. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 14:51:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA23462 for hackers-outgoing; Mon, 16 Oct 1995 14:51:14 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA23446 for ; Mon, 16 Oct 1995 14:50:58 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA16266 for ; Mon, 16 Oct 1995 22:50:38 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA23123 for freebsd-hackers@freebsd.org; Mon, 16 Oct 1995 22:50:38 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id WAA26234 for freebsd-hackers@freebsd.org; Mon, 16 Oct 1995 22:12:09 +0100 From: J Wunsch Message-Id: <199510162112.WAA26234@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Mon, 16 Oct 1995 22:12:09 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 16, 95 12:34:15 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1344 Sender: owner-hackers@freebsd.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > >Ah, i didn't knew that our locale support ain't complete yet. I was > >under the impression that the LC_CTYPE part was already ok. > > LC_CTYPE part _is_ already ok and because of it 'ls' with setlocale() > from main() for Japanese LANG becomes broken right now. But wouldn't that mean that enabling STARTUP_LOCALE by default would break `ls' for Japanese users then? I don't grok it. Somehow your opinions are self-contradictionary. Either, our locale support at least for LC_CTYPE is ready for prime time. Then, i don't see why we should not put a setlocale() into our programs. Or, it's still broken (e.g. for locales with a multibyte character represantation), then we cannot enable it by default. I'm saying this although i live in an area where proper locale support is at least very useful, in many cases even substantial. (The ports collection is out of my consideration for this. The first thing we have to get right is the base system. When this is done, we should think about the ports. Maybe we could find some hack similarly to the STARTUP_LOCALE thing especially tailored for the ports.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Oct 16 14:51:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA23500 for hackers-outgoing; Mon, 16 Oct 1995 14:51:22 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA23452 for ; Mon, 16 Oct 1995 14:51:09 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA16283 for ; Mon, 16 Oct 1995 22:50:50 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA23133 for freebsd-hackers@freebsd.org; Mon, 16 Oct 1995 22:50:50 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id WAA26218 for freebsd-hackers@freebsd.org; Mon, 16 Oct 1995 22:05:23 +0100 From: J Wunsch Message-Id: <199510162105.WAA26218@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Mon, 16 Oct 1995 22:05:23 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 16, 95 11:58:06 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 567 Sender: owner-hackers@freebsd.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > >I thought Russia lies half in Europe, too? :-) > > Well, when we found space in ISO8859-1 for all Russian chars, > it will be true. ISO-8859-1 does not represent Europe. It's at best representing Western Europe. (The latter being referencing itself often as ``Europe'', but i'd at least expect you to differentiate it correctly.) ;) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Oct 16 14:51:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA23482 for hackers-outgoing; Mon, 16 Oct 1995 14:51:19 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA23449 for ; Mon, 16 Oct 1995 14:51:04 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA16278 for ; Mon, 16 Oct 1995 22:50:48 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA23132 for freebsd-hackers@freebsd.org; Mon, 16 Oct 1995 22:50:47 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id VAA26193 for freebsd-hackers@freebsd.org; Mon, 16 Oct 1995 21:56:50 +0100 From: J Wunsch Message-Id: <199510162056.VAA26193@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Mon, 16 Oct 1995 21:56:49 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 16, 95 11:42:58 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 648 Sender: owner-hackers@freebsd.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > Do you really plan to convert all system and ports collection by inserting > reduced setlocale call there? All ctype programs need it expect few > ones which call setlocale by itself. In the end, this is the only way to go. I would accept some sort of a hack for the `ports' collection, but as for the base system, the programs should do whatever we expect them to do. In the source. Not inside some obscure crt0.o. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Oct 16 14:54:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA23598 for hackers-outgoing; Mon, 16 Oct 1995 14:54:36 -0700 Received: from dawnrazor.campus.luth.se (root@dawnrazor.campus.luth.se [130.240.193.73]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA23593 for ; Mon, 16 Oct 1995 14:54:32 -0700 Received: from localhost (offe@localhost [127.0.0.1]) by dawnrazor.campus.luth.se (8.6.12/8.6.9) with SMTP id WAA08655; Mon, 16 Oct 1995 22:54:05 +0100 Message-Id: <199510162154.WAA08655@dawnrazor.campus.luth.se> X-Authentication-Warning: dawnrazor.campus.luth.se: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6 4/21/95 To: "Justin T. Gibbs" Cc: hackers@freebsd.org Subject: Re: wtmp efficiency In-reply-to: Your message of "Mon, 16 Oct 1995 14:14:34 MST." <199510162114.OAA19312@aslan.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Oct 1995 22:54:04 +0100 From: Olof Johansson Sender: owner-hackers@freebsd.org Precedence: bulk I've found (and fixed) the problem. It's the fact that ftp and uucp connections get 'ftp' or 'uucp' + pid as tty_line in wtmp. The pid isn't removed when looking up the tty, so the list gets bigger and bigger. For 'ftp-only' wtmp files the time for parsing the file is proportional to n^2, where n is the number of entries in the file... (I have an exam on data structures and algorithms next week *grin*). The following patch fixes the problem. *** last.c Mon Aug 7 19:08:00 1995 --- lastold.c Mon Oct 16 22:43:48 1995 *************** *** 202,207 **** --- 202,215 ---- continue; } /* + * Fix tty-line for ftp and uucp entries. + * (same as in want(), see there for more info) + */ + if (!strncmp(bp->ut_line, "ftp", 3)) + bp->ut_line[3] = '\0'; + else if (!strncmp(bp->ut_line, "uucp", 3)) + bp->ut_line[4] = '\0'; + /* * if the line is '{' or '|', date got set; see * utmp(5) for more info. */ From owner-freebsd-hackers Mon Oct 16 15:13:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA24312 for hackers-outgoing; Mon, 16 Oct 1995 15:13:47 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA24307 for ; Mon, 16 Oct 1995 15:13:45 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id PAA19607; Mon, 16 Oct 1995 15:13:24 -0700 Message-Id: <199510162213.PAA19607@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: Olof Johansson cc: "Justin T. Gibbs" , hackers@freebsd.org Subject: Re: wtmp efficiency In-reply-to: Your message of "Mon, 16 Oct 1995 22:54:04 BST." <199510162154.WAA08655@dawnrazor.campus.luth.se> Date: Mon, 16 Oct 1995 15:13:23 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org Precedence: bulk >I've found (and fixed) the problem. > >It's the fact that ftp and uucp connections get 'ftp' or 'uucp' + pid as >tty_line in wtmp. The pid isn't removed when looking up the tty, so the list >gets bigger and bigger. >For 'ftp-only' wtmp files the time for parsing the file is proportional to >n^2, where n is the number of entries in the file... >(I have an exam on data structures and algorithms next week *grin*). Well you've put a finger on the problem, but your patch breaks last for "last ftp" or "last uucp". A better solution is to only add entries to the tty list that match our interest, and to remove entries from the tty list once we find the matching login time. Since the tty records are small, bcopying the next record over the matched record and freeing the next record should make the removal easy. Care to do the honors? -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Mon Oct 16 15:14:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA24396 for hackers-outgoing; Mon, 16 Oct 1995 15:14:42 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA24391 for ; Mon, 16 Oct 1995 15:14:39 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA25573; Mon, 16 Oct 1995 15:09:02 -0700 From: Terry Lambert Message-Id: <199510162209.PAA25573@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 15:09:02 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, kaleb@x.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Jan 16, 95 11:38:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4341 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >> >IMHO, the base utilities that use should properly initialize > >> >the locale instead of relying on that hack. (The hack is useful to > >> >force programs that don't like to handle locale's, but base utilities > >> >of the system are expected to do it right theirselves.) > >> > >> I have nothing against reverting this variable to > >> DISABLE_STARTUP_LOCALE f.e. If you remember I plan to make startup locale > >> as default for all program, but some peoples disagree, so I introduce > >> ENABLE_STARTUP_LOCALE. > > >I also thing that the crt0 is the *wrong* place to do the locale work, > >which really belongs as a call in main(). > > It seems that every new person appears immediately starts to says > the same wrong things as other starts instead of reading full > discussion first where all this stuff already explained several times. I've only been working on user interface internationalization for more than 10 years, and OS internationalization for 6 years. You may be right that I have insufficient context. But I doubt it. > It is very bad karma to call setlocale from main for ctype-oriented > programs when chars size assumed <= 8bit. > I already tries explain it to Joerg and if you really interested, > you can found answer in my previous messages. > Only crt0 is proper place for this things. Then use XPG/3 localization techiques instead of XPG/4 multibyte localization. The two are not incompatible. The problem you are facing here is that in that case, you have half the designated locale definitions that you should have to support it. It is a data problem and an XPG code compatability problem, not a problem in the code doing the calls. The crt0 hack is a kludge that supposedly "fixes" non-internationalized programs that are otherwise 8 bit clean. The reason it is that is that the default C locale is not i18n clean in its undefined behaviour. It should not be there. 0xa3 will display the same for you no matter which 8859-x locale you pick, except the current C locale, which I think is wrong. The problem is that the current C locale renders some printable characters unprintiable, etc. by virtue of the way the ctype.h macros operate. Well, fix the C locale's undefined behaviour to be the same as the defined 8859-1 behaviour. Problem solved. > >It is wrong to "fix" broken use of a programming model by causing > >broken use of the startup model in it's place. > > > >Making this broken startup code implicit rather than explicit (by changing > >from a positive to a negative environment test) is just plain wrong. > > Well, what you consider as 'broken' most of user expect to see as 'i18n'. No. You are misinterpreting what I have said. The brokenness is in a setlocale() call in a non-internationalized piece of code that happens to be (maybe) 8bit clean because the default C locale happens to also be broken. Fix the C locale, not the crt0.o. Then, as time permits, fix the locale unaware code. > Why it is 'broken' to have right ctype at startup? Try to ask your > customers, almost every user which directly sets "LANG" assume that > 'ls' f.e. must be affected immediately and _not_ by additional hidden magic > of 'setenv ENABLE_STARTUP_LOCALE'. If you don't want any startup code, > simple not set your "LANG". That makes ls broken for not explicitly calling setlocale(). Not setting 'LANG' is not going to recover my 24k for a NULL program. > Where was you when Kaleb suggest more uglier hack with default code > table propogating? Hiding under a rock, apparently, or I would have called him on it. I probably *did* call him on it. > My hack keeps right ctype in all cases and his hack works only for > 8859-1 and not works even for 8859-n, n != 1. As long as the characters are passed through unadulterated, there is no difference for n == 1 and n != 1 in the non-setlocale() called case, which is the issue. If the damn thing wasn't being called and the C locale were correctly defined for "undefined" code points, then there would not be a problem. Calling "setlocale()" for an otherwise non-internationalized program is a big mistake, and just compounds the C locale mistake. Correct the right code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 15:16:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA24504 for hackers-outgoing; Mon, 16 Oct 1995 15:16:25 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA24491 for ; Mon, 16 Oct 1995 15:16:20 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA25592; Mon, 16 Oct 1995 15:11:18 -0700 From: Terry Lambert Message-Id: <199510162211.PAA25592@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Mon, 16 Oct 1995 15:11:17 -0700 (MST) Cc: hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de In-Reply-To: <199510160028.UAA06809@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 15, 95 08:28:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 841 Sender: owner-hackers@FreeBSD.org Precedence: bulk > Expo follows RFC 821/822 to the letter. It's not convenient, but it does > blindly adhere to the rules. Everyone else in the world seems to be > overlooking the rules, mostly it seems because it's inconvenient to > to follow the rules set out in the RFCs. Strongly agreed. > Along the same line, it'd be really convenient if the default chartype > table had its right side populated for ISO8859-1 so that broken tools > could still manage to do the right thing most of the time. My major premise in this whole discussion is that the bogus code in crt0.o is a result of trying to correct the C locale deficiencies without actually correcting the C locale. It is a kludge on a bug, not a bugfix. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 15:19:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA24686 for hackers-outgoing; Mon, 16 Oct 1995 15:19:33 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA24679 for ; Mon, 16 Oct 1995 15:19:29 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA25604; Mon, 16 Oct 1995 15:14:13 -0700 From: Terry Lambert Message-Id: <199510162214.PAA25604@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 15:14:13 -0700 (MST) Cc: bde@zeta.org.au, hackers@freefall.freebsd.org, kaleb@x.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 16, 95 04:44:58 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1032 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >>Bruce, I agree with you and POSIX agree with us. > >>Default table must be strict ASCII per POSIX. > >>So, we can close this table propogating subject. > > >Does POSIX mention ASCII? ANSI allows other encodings > >of course, and is only strict for letters and digits, > >but only letters are very important. > > Well 1003.1 says something about minimal subset to run C pgms. > Comparing ASCII and 8859-1 is clear that ASCII is more minimal. > > Here some explanation of this term taken directly from POSIX > working gtoup ISO/IEC JTC1/SC22/WG15 - POSIX: locale collection. > They have VERY different locales for POSIX default and 8859-1 > and POSIX default conforms ASCII, see below. > (If someone interested, I can post their 8859-1 locale too). OK. POSIX is IEEE. What does ISO say? I believe it relaxes the values allowable in the "undefined" or "implementation defined" cases. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 15:29:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA25623 for hackers-outgoing; Mon, 16 Oct 1995 15:29:30 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA25616 for ; Mon, 16 Oct 1995 15:29:27 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id PAA23695; Mon, 16 Oct 1995 15:29:25 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id PAA15796; Mon, 16 Oct 1995 15:23:43 -0700 Message-Id: <199510162223.PAA15796@corbin.Root.COM> To: "Justin T. Gibbs" cc: Olof Johansson , hackers@freebsd.org Subject: Re: wtmp efficiency In-reply-to: Your message of "Mon, 16 Oct 95 15:13:23 PDT." <199510162213.PAA19607@aslan.cdrom.com> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 16 Oct 1995 15:23:40 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >>I've found (and fixed) the problem. >> >>It's the fact that ftp and uucp connections get 'ftp' or 'uucp' + pid as >>tty_line in wtmp. The pid isn't removed when looking up the tty, so the list >>gets bigger and bigger. >>For 'ftp-only' wtmp files the time for parsing the file is proportional to >>n^2, where n is the number of entries in the file... >>(I have an exam on data structures and algorithms next week *grin*). > >Well you've put a finger on the problem, but your patch breaks last for >"last ftp" or "last uucp". > >A better solution is to only add entries to the tty list that match our >interest, and to remove entries from the tty list once we find the matching >login time. Since the tty records are small, bcopying the next record >over the matched record and freeing the next record should make the removal >easy. Care to do the honors? Actually, I'm writing this change right now, and will post the changes when I'm finished... There are some other optimizations I'm making at the same time. -DG From owner-freebsd-hackers Mon Oct 16 15:38:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA26076 for hackers-outgoing; Mon, 16 Oct 1995 15:38:20 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA26069 for ; Mon, 16 Oct 1995 15:38:15 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA25657; Mon, 16 Oct 1995 15:33:04 -0700 From: Terry Lambert Message-Id: <199510162233.PAA25657@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 15:33:03 -0700 (MST) Cc: kaleb@x.org, hackers@freefall.freebsd.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 16, 95 07:21:56 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2673 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >>A nice suggestion. Too bad it doesn't work. ANSI/POSIX1 say that a > >>program does the equivalent of setlocale(LC_ALL, "C") on startup. Given > >>that ls, and I gather everything else, disregard my LANG, LC_ALL, and > >>LC_CTYPE environment variables, I'm left wondering how it is you think > >>that using the "proper locale" will help. Are you assuming that I'm > >>using the undocumented hack of setting the ENABLE_STARTUP_LOCALE > >>environment variable? > > Briefly says, I disagree with default table propogation to 8859-1 > (well, maybe agree with propogation to KOI8-R :-) because: > > 1) It violates POSIX default "C" locale description. But not the ISO/ANSI C description. I can put in anything for "undefined" that I damn well please. Including 8859-1. > 2) It breaks all >=8bit charsets which names != 8859-1. This is patently false. What results is a predominantly 8-bit clean interface that has 0x00-0x1f,0x80-0x9f shown a controls, and everything else shown as printable characters. This is valid for all 8859-x display/input systems, since the reuse of the code points are not transformed by this (8859-x does not encode characters in those locations). The only potentially incorrect behaviour is on blanks not being interpreted as blanks. If you want a blank, you shouldn't be using some wild code point other than 0x20 anyway. You get what you deserve. At this point, that would cause the resulting behaviour to be "undefined". This is acceptable according to ISO interpretation of X3J11 anyway. You use an undefined character, you get wierd grap on your screen. The problems you will encounter in this circumstance are all *very* specific to cases where a single file system is being used by multiple nationalities of clients. Since the locale mechanism is a *internationalization* mechanism, not a *multinationalization* mechanism, this is in fact correct behaviour. The difference is that "internationalization" is defined as enabling for localization to a particular (read as *single*) language. Thus this behaviour is acceptable and, in fact, expected. If you want *multinationalization*, use ISO10646, code page 0. That is, 16 bit Unicode. It won't buy you font selection, but unless you are a language bigot, that shouldn't matter on file names. If you care, start lobbying for allocation of code pages other than 0 in 10646. Good luck on your lobbying, you'll need it. I hope you don't mind if I lobby for RTF encoding for language bigots, since they are in the minority. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 15:44:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA26321 for hackers-outgoing; Mon, 16 Oct 1995 15:44:21 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA26303 for ; Mon, 16 Oct 1995 15:44:09 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA25686; Mon, 16 Oct 1995 15:38:52 -0700 From: Terry Lambert Message-Id: <199510162238.PAA25686@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 15:38:52 -0700 (MST) Cc: phk@critter.tfs.com, bde@zeta.org.au, hackers@freefall.freebsd.org, j@uriah.heep.sax.de, kaleb@x.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 16, 95 11:42:58 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 640 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >> 2) We already discuss that bloat on early days and agree > >> let it be. > >No, we agreed to let it stay in crt0.s until it had been put the right > >place. crt0.s is NEVER the right place. > > I don't think so. It was probably not an explicit agreement. It would have been enough that this was assumed to be a temporary fix to keep me (and I presume him) from complaining, making it: "our understanding was that it was temporary" It was certainly my inderstanding that this was the case. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 17:18:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA00378 for hackers-outgoing; Mon, 16 Oct 1995 17:18:06 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA00350 for ; Mon, 16 Oct 1995 17:17:59 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id QAA09567 for ; Mon, 16 Oct 1995 16:57:47 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA25790; Mon, 16 Oct 1995 16:52:02 -0700 From: Terry Lambert Message-Id: <199510162352.QAA25790@phaeton.artisoft.com> Subject: Re: NetBSD/FreeBSD To: chuck@fang.cs.sunyit.edu (Charles Kenneth Green - PRC) Date: Mon, 16 Oct 1995 16:52:02 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <199510161329.JAA18504@fang.cs.sunyit.edu> from "Charles Kenneth Green - PRC" at Oct 16, 95 09:29:43 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 711 Sender: owner-hackers@freebsd.org Precedence: bulk > Looking at the possibility of adding POSIX threads to FreeBSD, I > found a group at MIT that has added POSIX threads to netbsd-1.0. I know > that both systems have thier roots in the 4.4-lite distribution but just > how much different are they now? Does this seem like a viable place to > begin from in order to accomplish this task? This would be pthreads. It already exists for FreeBSD. The implemenatations aren't very different at the user space level, so porting something like that is no effort. I still believe pthreads is insufficient for HotJava. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 17:18:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA00391 for hackers-outgoing; Mon, 16 Oct 1995 17:18:07 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA00356 for ; Mon, 16 Oct 1995 17:18:00 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id RAA09638 for ; Mon, 16 Oct 1995 17:02:35 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id BAA23273 ; Tue, 17 Oct 1995 01:03:21 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id BAA29081 ; Tue, 17 Oct 1995 01:03:21 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id AAA28318; Tue, 17 Oct 1995 00:50:54 +0100 (MET) From: Ollivier Robert Message-Id: <199510162350.AAA28318@keltia.freenix.fr> Subject: Re: make release To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 17 Oct 1995 00:50:53 +0100 (MET) Cc: didier@omnix.fr.org, hackers@freebsd.org In-Reply-To: <199510132242.XAA05210@uriah.heep.sax.de> from "J Wunsch" at Oct 13, 95 11:42:42 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1215 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk It seems that J Wunsch said: > It's not even possible _with_ a CVS tree (in particular for you living > in France), if the DES and Kerberos bits are missing. Well, one may get the intl bits on ftp.internat.freebsd.org. It should enable you to compile it. I don't have the place to do a distribution though or I'd do it for some friends here. It is sometimes frustrating to say to them "go get it on some FTP site" when you could generate it yourself. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #0: Sat Oct 14 19:05:10 MET 1995 From owner-freebsd-hackers Mon Oct 16 17:31:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA01020 for hackers-outgoing; Mon, 16 Oct 1995 17:31:46 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA00996 for ; Mon, 16 Oct 1995 17:31:42 -0700 Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id RAA09811 for ; Mon, 16 Oct 1995 17:19:44 -0700 Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA26861; Mon, 16 Oct 1995 17:05:23 -0700 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA12631; Mon, 16 Oct 1995 20:05:17 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id UAA03092; Mon, 16 Oct 1995 20:05:46 GMT Message-Id: <199510162005.UAA03092@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: Bruce Evans Cc: se@zpr.uni-koeln.de, hackers@freebsd.org Subject: Re: IPX now available In-Reply-To: Your message of "Mon, 16 Oct 1995 11:42:07 +1000." <199510160142.LAA05419@godzilla.zeta.org.au> X-Mailer: exmh version 1.5omega 10/6/94 Date: Mon, 16 Oct 1995 20:05:44 +0000 From: Matt Thomas Sender: owner-hackers@freebsd.org Precedence: bulk In <199510160142.LAA05419@godzilla.zeta.org.au> , you wrote: > >significant sense. However, when the world is dynamic the autoconfig > >code now becomes passive and the LKMs are the active components. > > >Indeed, one very real way to look at this would be to use the DATA_SET > >capabilities that currently exist to store a vector of configuration/ > >initialization entries. So when the kernel is linked, all the > >initializers for devices, file systems, protocols, etc. are present in > >this data set. The system will define a set of synchronization points and > >ordering points within each sync point. So when the kernel initializes, it > >sorts these configuration entries and calls them one by one in order. > > >This results in a number of benifits. The first is that the exact same > >modules can be used for both static-linked kernel and dynamically loaded > >kernel. Another benifit is that you can develop and debug almost all > >the mechanisms needed for a truly dynamic kernel using the existing static > >kernel framework. > > I think this is backwards. I see linker vectors as just a trick to > help initialize things when you don't have fully dynamic initialization. > I think the static framework should be changed to look more like the > dynamic framework instead of vice versa. In a dynamic kernel, you'd just read the init linker vector from the module and process each entry (placing it into the ordered init table in the right place. Thinking about it, it would make sense to have a callback mechanism instead where each can schedule a routine to be called after a sync point is reached (after its first sync point, that is -- see below). But in either case, the point is that the each module determines when it gets called to do something. There is no de-facto established like there currently is in init_main(). Note that in a dynamically linked kernel, there is no /kernel so that you will need to something to replace nlist("/kernel"). > >... > >I strongly disagree. In my view, a LKM controls its own fate. The kernel > >(or other LKMs on which this LKM depends) merely provided services which it > >can use. Indeed, as far as the system is concerned there should be no > >difference between a FS LKM or a device LKM or protocol LKM or a syscall LKM. > >Once the LKM's configuration entry point has been called, the LKM is in > >control. > > Yes, the dynamic framework (at least for device drivers) should be: > > . a single entry point (for initialization) in each module > . autonomous modules > > The only difference for the static framework should be that the list > of initialization routines is kept in a vector instead of in a file. Which is what I stated above (expect that instead of just a vector of routine pointers, one had a vector of struct pointers which had ordering information as well as the function pointer. > Vectors aren't suitable for handling complicated orderings. The linker > may put things in the wrong order so you need a meta-routine to decide > the order or more intelligence in the module initialization routines. I > think that except for early kernel initialization, all the intelligence > should be in the module initialization routines. Agreed. As I said, when the kernel initializes it (the kernel via a meta-routine -- not the loader) sorts the module init vector using the information in each structure. (since almost all modules will need to be called as somepoint, it makes sense to have at least code the call in a small static structure rather than requiring some code to invoke a callback registration routine.) > Device drivers will > need to be able to sleep in their probe and attach routines for other > reasons. When tsleep() at probe and attach time is implemented, > complicated time-dependent orderings (aka races :-) will be easy to > implemented - just sleep until the modules that you depend on are > loaded. It depends on when drivers will be probed but if we assume it's before the process initialization, then this begs for kernel threads. While highly desirable, I think kernel threads would be overkill if added just for this. Instead, use of timeout() and proper sync points would achieve the same capability at far less implementation cost. When I talk about sync points, I'm talking about when major parts of the kernel become ready for use. These include (but are not limited to and not in the temporal order of): timer services VM (including malloc/free) scheduler ready core networking (netisr/domain). ready device configuration done rootfs available going to single user For instance, my de driver would register callback after PCI support is ready, while core networking wait just for the VM init to complete). There's an awful lot of time that the kernel spends waiting for something to finish that it could be using to do something more productive. While kernel threads would be an elegant way of doing this, an event driven dispatcher could be just as effective and simpler to implement. Matt Thomas Internet: matt@lkg.dec.com 3am Software Foundry WWW URL: Westford, MA Disclaimer: Digital disavows all knowledge of this message From owner-freebsd-hackers Mon Oct 16 17:46:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA01316 for hackers-outgoing; Mon, 16 Oct 1995 17:46:06 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA01311 for ; Mon, 16 Oct 1995 17:46:03 -0700 Received: by sovcom.kiae.su id AA29146 (5.65.kiae-1 ); Tue, 17 Oct 1995 02:58:46 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 02:58:46 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id CAA00568; Tue, 17 Oct 1995 02:57:56 +0300 To: Terry Lambert Cc: bde@zeta.org.au, hackers@freefall.freebsd.org, j@uriah.heep.sax.de, kaleb@x.org, phk@critter.tfs.com References: <199510162238.PAA25686@phaeton.artisoft.com> In-Reply-To: <199510162238.PAA25686@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 15:38:52 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 02:57:56 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 40 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1361 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510162238.PAA25686@phaeton.artisoft.com> Terry Lambert writes: >> >> 2) We already discuss that bloat on early days and agree >> >> let it be. >> >No, we agreed to let it stay in crt0.s until it had been put the right >> >place. crt0.s is NEVER the right place. >> >> I don't think so. >It was probably not an explicit agreement. >It would have been enough that this was assumed to be a temporary fix >to keep me (and I presume him) from complaining, making it: > "our understanding was that it was temporary" >It was certainly my inderstanding that this was the case. Now you vote for solution which is simple subcase of my crt0 hack: setlocale(LC_ALL, ""); /* my */ changed to setlocale(LC_ALL, "lt_LN.ISO_8859-1"); /* your */ Since your variant is static (and my is adjusted to current LANG), you don't need even such call and can patch default table directly. For LANG = 8859-1 both variants are equal, but for LANG != 8859-1 you give some strange values calling them 'default' and I give full correct ctype/time/collate table. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 17:46:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA01337 for hackers-outgoing; Mon, 16 Oct 1995 17:46:14 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA01329 for ; Mon, 16 Oct 1995 17:46:09 -0700 Received: by sovcom.kiae.su id AA28698 (5.65.kiae-1 ); Tue, 17 Oct 1995 02:50:58 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 02:50:58 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id CAA00541; Tue, 17 Oct 1995 02:49:45 +0300 To: "Kaleb S. KEITHLEY" , Terry Lambert Cc: hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de References: <199510162211.PAA25592@phaeton.artisoft.com> In-Reply-To: <199510162211.PAA25592@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 15:11:17 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 02:49:45 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 30 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1300 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510162211.PAA25592@phaeton.artisoft.com> Terry Lambert writes: >> Along the same line, it'd be really convenient if the default chartype >> table had its right side populated for ISO8859-1 so that broken tools >> could still manage to do the right thing most of the time. >My major premise in this whole discussion is that the bogus code in >crt0.o is a result of trying to correct the C locale deficiencies >without actually correcting the C locale. >It is a kludge on a bug, not a bugfix. Lets consider, how your proposed hack differs from mine: You plan to force non-locale-aware programs to 8859-1, it works right for 8859-1 users as exactly matched case, so for such users my hack == your hack, no diffs exists. When users are not 8859-1, your hack != my hack, because you load so-called 'default udefined table' and I load table which match current charset. Lets consider, what is better for user, some 'default undefined hack' or code table which match his charset exactly? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 17:46:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA01363 for hackers-outgoing; Mon, 16 Oct 1995 17:46:25 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA01356 for ; Mon, 16 Oct 1995 17:46:20 -0700 Received: by sovcom.kiae.su id AA27979 (5.65.kiae-1 ); Tue, 17 Oct 1995 02:41:32 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 02:41:32 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id CAA00513; Tue, 17 Oct 1995 02:40:39 +0300 To: Terry Lambert Cc: hackers@freefall.freebsd.org, kaleb@x.org References: <199510162233.PAA25657@phaeton.artisoft.com> In-Reply-To: <199510162233.PAA25657@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 15:33:03 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 02:40:38 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 40 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1829 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510162233.PAA25657@phaeton.artisoft.com> Terry Lambert writes: >> 2) It breaks all >=8bit charsets which names != 8859-1. >This is patently false. What results is a predominantly 8-bit clean >interface that has 0x00-0x1f,0x80-0x9f shown a controls, and everything >else shown as printable characters. >This is valid for all 8859-x display/input systems, since the reuse of >the code points are not transformed by this (8859-x does not encode >characters in those locations). You consider one very simple case (isprint/iscontrol only) and think that it is a proof. What you can say about ispunct() f.e.? It is clearly differ into 8859-1 and 8859-5 f.e., islower/isupper differs too. tolower/toupper differs too. Even isalpha differs. >The only potentially incorrect behaviour is on blanks not being interpreted >as blanks. If you want a blank, you shouldn't be using some wild code >point other than 0x20 anyway. You get what you deserve. Well, isspace differs too. >The problems you will encounter in this circumstance are all *very* >specific to cases where a single file system is being used by multiple >nationalities of clients. No it is different problem. By setting LANG for something != 8859-1 (for programs that understands it) I assume that programs which not understands it still works right. If they are strict ASCII, I automatically protected from any unwanted effects. If they are 8859-1 I need to classify various unwanted effects for each != 8859-1 charset as 'default undefined behaviour'. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 17:47:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA01405 for hackers-outgoing; Mon, 16 Oct 1995 17:47:00 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA01397 for ; Mon, 16 Oct 1995 17:46:57 -0700 Received: by sovcom.kiae.su id AA26923 (5.65.kiae-1 ); Tue, 17 Oct 1995 02:27:40 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 02:27:39 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id CAA00417; Tue, 17 Oct 1995 02:23:38 +0300 To: Terry Lambert Cc: hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, kaleb@x.org References: <199510162209.PAA25573@phaeton.artisoft.com> In-Reply-To: <199510162209.PAA25573@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 15:09:02 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 02:23:38 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 84 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3523 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510162209.PAA25573@phaeton.artisoft.com> Terry Lambert writes: >I've only been working on user interface internationalization for more >than 10 years, and OS internationalization for 6 years. I too but my case was restricted mostly to russian language. >The crt0 hack is a kludge that supposedly "fixes" non-internationalized >programs that are otherwise 8 bit clean. >The reason it is that is that the default C locale is not i18n clean in >its undefined behaviour. >It should not be there. 0xa3 will display the same for you no matter >which 8859-x locale you pick, except the current C locale, which I think >is wrong. >The problem is that the current C locale renders some printable characters >unprintiable, etc. by virtue of the way the ctype.h macros operate. >Well, fix the C locale's undefined behaviour to be the same as the defined >8859-1 behaviour. Problem solved. It seems that you miss the point here. Most harmful are macros such as isprint(), islower()/isupper(), isalpha(), ispunct(), etc. all of them are different for various 8bit charsets, f.e. isalhpa(8859-1) != isalpha(KOI8-R). If you stuck with one particular version, f.e. 8859-1, is*() functions will return incorrect values for any other charset used screwing your screen and keyboard input. I.e. 8859-1 toupper() can produce very strange char for KOI8-R input. Or 8859-1 checking input for ispunct() can allow very strange KOI8-R chars sneak in. Or 8859-1 isalhpa() for output can print very strange chars for KOI8-R, etc. Don't forget, I use KOI8-R only for example, you can find some 8859-* font to substitute instead of this name. >Fix the C locale, not the crt0.o. Then, as time permits, fix the locale >unaware code. What do you mean by fixing C locale exactly? >As long as the characters are passed through unadulterated, there is >no difference for n == 1 and n != 1 in the non-setlocale() called case, >which is the issue. If the damn thing wasn't being called and the >C locale were correctly defined for "undefined" code points, then there >would not be a problem. What you mean by unaltered? They are unaltered, but they belongs to different classes in different charsets, real separator is is*() functions. >Calling "setlocale()" for an otherwise non-internationalized program is >a big mistake, and just compounds the C locale mistake. Correct the >right code. BTW, when C program is known 8bit clean, what I and my users want from FreeBSD is proper interaction with russian language. It means that 1) all is*() macros must be correct for russian charset (LC_CTYPE). 2) strftime must return national data (LC_TIME). 3) National sorting must works (LC_COLLATE). Now all that goals are reached by 'setenv ENABLE_STARTUP_LOCALE' and without any program modifications. It is especially essential when program isn't FreeBSD native but comes from 3rd party, i.e. ports area. Moreover, they can be reached on any remote system too, includes freefall f.e. The same words are true for 8859-1 users too, not only for KOI8-R users. Maybe this functionality isn't kosher but you even can't imagine how it is useful. If you know "proper way" to do things and keeps this goals non-broken too, I am all ears. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 17:56:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA01777 for hackers-outgoing; Mon, 16 Oct 1995 17:56:22 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA01772 for ; Mon, 16 Oct 1995 17:56:19 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA25909; Mon, 16 Oct 1995 17:51:14 -0700 From: Terry Lambert Message-Id: <199510170051.RAA25909@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 17:51:14 -0700 (MST) Cc: kaleb@x.org, terry@lambert.org, hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 17, 95 02:49:45 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2947 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >> Along the same line, it'd be really convenient if the default chartype > >> table had its right side populated for ISO8859-1 so that broken tools > >> could still manage to do the right thing most of the time. > > >My major premise in this whole discussion is that the bogus code in > >crt0.o is a result of trying to correct the C locale deficiencies > >without actually correcting the C locale. > > >It is a kludge on a bug, not a bugfix. > > Lets consider, how your proposed hack differs from mine: > You plan to force non-locale-aware programs to 8859-1, > it works right for 8859-1 users as exactly matched case, > so for such users my hack == your hack, no diffs exists. For one, my "hack" meets the definition of the ISO ratification of X3J11 and at the same time conforms to ISO 8859-x character set rules. It works for all ISO8859-x users, not just ISO8859-1. The difference is wherein the character code points are set based on columnar location. This was, in fact, one of the stated design goals of the 8859-x standards. > When users are not 8859-1, your hack != my hack, because > you load so-called 'default udefined table' and I load > table which match current charset. Lets consider, what is better > for user, some 'default undefined hack' or code table > which match his charset exactly? First of all, since it conforms to the letter of the standards, the approach I have suggested is not technically a hack. You suggested soloution is in fact a hack. Second of all, my soloution does not load a locale, so nothing is "loaded"; instead, pointer is agregate initialized to a static "C" locale table. This is, in fact, the preferred method of dealing with this issue *without* calling setlocale in crt0.o or as the first thing in main(), according to the standards documents. The one real issue is the collating sequence. This is a non-issue for "7-bit-ASCII-first" sort orders. They will be correct. It *IS* an issue for "non-internationalized code pretending to be internationalized". I have absolutely no sympathy for such code; it should be fixed. Your case has sympathy for this bogus code by making it work at the expense of breaking other things. You have drawn the following figure: ,------. | | | B |D | | `------+--. C |A | `--' And expanded the supported area from {A} to {A,B}, at the expense of {C,D}. In point of fact, the figure should be drawn as: ,--. | | B |D | | | ,------+--+ | C |A | `------+--' And {B}, the set of programs pretending to be internationalized but lacking an explicit setlocale() call, are what should not be supported. If you need to make code that isn't internationalized and you want a hack, call the setlocale(,"") in main() if the desired program. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 17:57:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA01804 for hackers-outgoing; Mon, 16 Oct 1995 17:57:45 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA01799 for ; Mon, 16 Oct 1995 17:57:40 -0700 Received: by sovcom.kiae.su id AA03298 (5.65.kiae-1 ); Tue, 17 Oct 1995 03:52:52 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 03:52:52 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id DAA00657; Tue, 17 Oct 1995 03:30:24 +0300 To: David Dawes , Ollivier Robert Cc: hackers@freefall.freebsd.org, kaleb@x.org References: <199510162300.AAA28238@keltia.freenix.fr> In-Reply-To: <199510162300.AAA28238@keltia.freenix.fr>; from Ollivier Robert at Tue, 17 Oct 1995 00:00:45 +0100 (MET) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 03:30:23 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 27 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1067 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510162300.AAA28238@keltia.freenix.fr> Ollivier Robert writes: >It seems that David Dawes said: >> Yes, they are different. Can someone give me a precise method of >> reproducing this problem? I routinely have LANG set to en_AU.ISO8859-1 >I have the following by default in my environment : >LANG=fr_FR.ISO_8859-1 >LC_CTYPE=iso_8859_1 LC_CTYPE=xxx does nothing, iso_8859_1 isn't valid value for LC_CTYPE. Having both variables setted, and LC_CTYPE incorrectly setted cause setlocale does nothing and exits. >As soon as I switch LC_CTYPE to fr_FR.ISO_8859-1, all xterms started from >this terminal will dump core (well, they won't because xterm is setuid >root), each time. The signal is SEGV. I already sent GDB stack trace for this case. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 18:08:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA02075 for hackers-outgoing; Mon, 16 Oct 1995 18:08:03 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA02069 for ; Mon, 16 Oct 1995 18:07:59 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id LAA16860; Tue, 17 Oct 1995 11:04:05 +1000 Date: Tue, 17 Oct 1995 11:04:05 +1000 From: Bruce Evans Message-Id: <199510170104.LAA16860@godzilla.zeta.org.au> To: bde@zeta.org.au, mark@grondar.za Subject: Re: Creating a /dev/random Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >> To avoid this, use the existing buffer `zbuf', which is freed correctly. >> There is no need for another variable - local variables are per process. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Perhaps `zbuf' should be renamed `buf'. >I don't understand something here - what happens if the one process is >reading both /dev/zero and /dev/random? will the two not then try to >share buf/zbuf and screw up? See above >> is inelegant anyway. Perhaps there should be a zeroout() function to >> optimize this important (;-) device. >...or only c bytes should be zero'ed out? Good idea. Bruce From owner-freebsd-hackers Mon Oct 16 18:09:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA02136 for hackers-outgoing; Mon, 16 Oct 1995 18:09:44 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA02127 for ; Mon, 16 Oct 1995 18:09:41 -0700 Received: from exalt.x.org by expo.x.org id AA08456; Mon, 16 Oct 95 20:06:18 -0400 Received: from localhost by exalt.x.org id UAA25504; Mon, 16 Oct 1995 20:06:14 -0400 Message-Id: <199510170006.UAA25504@exalt.x.org> To: ache@astral.msk.su Cc: hackers@freefall.FreeBSD.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Tue, 17 Oct 1995 02:23:38 EST. Organization: X Consortium Date: Mon, 16 Oct 1995 20:06:14 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk >It means that >1) all is*() macros must be correct for russian charset (LC_CTYPE). >2) strftime must return national data (LC_TIME). >3) National sorting must works (LC_COLLATE). A properly localized program will do all these things. >Now all that goals are reached by 'setenv ENABLE_STARTUP_LOCALE' >and without any program modifications. EXCEPT THAT VIOLATES ANSI/POSIX/ISO C, which stipulates that on the entry to main() the program must be in the C locale. People who use this hack on correctly written programs find that it breaks their programs in not very subtle ways, as you've already found with the i18n-aware xterm that XFree86 distributes. >It is especially essential when >program isn't FreeBSD native but comes from 3rd party, i.e. >ports area. Moreover, they can be reached on any remote system >too, includes freefall f.e. Then perhaps the process of putting something into ports should include minimally localizing the program to set the locale to whatever the user has set in his or her LC_ALL, LC_CTYPE, or LANG environment variable. Any well written program would have done that anyway. If you use an X toolkit (Xt with a widget set) then Xt will do it for you. Just because some people write broken programs is no reason to impose such a hack on those who write correct programs. >The same words are true for 8859-1 users too, not only for KOI8-R >users. >Maybe this functionality isn't kosher but you even can't imagine how >it is useful. Let me get this straight. You're willing to compromise ANSI/POSIX/ISO compliance because the functionality is useful. I'm not even asking to compromise compliance and still get some useful behavior, and your response is to make up completely bogus arguments like ANSI requires the C locale to be strictly ASCII, no more, no less. I wonder if NetBSD is this broken? I'm starting to think it might be time to switch camps. >If you know "proper way" to do things and keeps this goals non-broken too, >I am all ears. Both Terry and I have explained why it's okay to populate the default chartype table differently than it is now -- Terry is a very eloquent writer, I think he did a better job than I did -- listen to Terry. -- Kaleb From owner-freebsd-hackers Mon Oct 16 18:12:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA02253 for hackers-outgoing; Mon, 16 Oct 1995 18:12:43 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA02248 for ; Mon, 16 Oct 1995 18:12:40 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id BAA23269 ; Tue, 17 Oct 1995 01:03:21 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id BAA29078 ; Tue, 17 Oct 1995 01:03:19 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id AAA28238; Tue, 17 Oct 1995 00:00:45 +0100 (MET) From: Ollivier Robert Message-Id: <199510162300.AAA28238@keltia.freenix.fr> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: dawes@rf900.physics.usyd.edu.au (David Dawes) Date: Tue, 17 Oct 1995 00:00:45 +0100 (MET) Cc: kaleb@x.org, ache@astral.msk.su, hackers@freefall.freebsd.org In-Reply-To: <199510160139.LAA02341@rf900.physics.usyd.edu.au> from "David Dawes" at Oct 16, 95 11:39:32 am X-Operating-System: FreeBSD 2.2-CURRENT ctm#1215 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk It seems that David Dawes said: > Yes, they are different. Can someone give me a precise method of > reproducing this problem? I routinely have LANG set to en_AU.ISO8859-1 I have the following by default in my environment : LANG=fr_FR.ISO_8859-1 LC_CTYPE=iso_8859_1 As soon as I switch LC_CTYPE to fr_FR.ISO_8859-1, all xterms started from this terminal will dump core (well, they won't because xterm is setuid root), each time. The signal is SEGV. > a problem. I'm using the version of xterm in XFree86 3.1.2. I don't have > ENABLE_STARTUP_LOCALE (or any other LANG stuff) enabled in /etc/sysconfig. I have my crt0 compiled with ENABLE_STARTUP_LOCALE and the variable in my environment as well. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #0: Sat Oct 14 19:05:10 MET 1995 From owner-freebsd-hackers Mon Oct 16 18:14:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA02298 for hackers-outgoing; Mon, 16 Oct 1995 18:14:00 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA02293 for ; Mon, 16 Oct 1995 18:13:55 -0700 Received: by sovcom.kiae.su id AA04714 (5.65.kiae-1 ); Tue, 17 Oct 1995 04:11:49 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 04:11:49 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id EAA00789; Tue, 17 Oct 1995 04:09:49 +0300 To: Terry Lambert Cc: hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, kaleb@x.org References: <199510170051.RAA25909@phaeton.artisoft.com> In-Reply-To: <199510170051.RAA25909@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 17:51:14 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 04:09:48 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 43 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1873 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510170051.RAA25909@phaeton.artisoft.com> Terry Lambert writes: >For one, my "hack" meets the definition of the ISO ratification of X3J11 >and at the same time conforms to ISO 8859-x character set rules. >It works for all ISO8859-x users, not just ISO8859-1. >The difference is wherein the character code points are set based on >columnar location. This was, in fact, one of the stated design goals >of the 8859-x standards. Well, lets consider D7 char from 8859-1 exactly: is it ispunct() too f.e, in 8859-5? Lets consider DF char exactly, is it islower() too f.e. in 8859-5? BTW, why we even forced to be strictly in 8859 bounds? Why another charset with lower half equal to ASCII can't live too? >The one real issue is the collating sequence. This is a non-issue for >"7-bit-ASCII-first" sort orders. They will be correct. It *IS* an >issue for "non-internationalized code pretending to be internationalized". >I have absolutely no sympathy for such code; it should be fixed. Well, it should be fixed by *WHOM* and *WHEN*? As you don't have sympathy, maybe you take this task as contacting to authors, fixing, etc. for each such program? Some of such programs needed right now, and I can't say to my users that they 'should be fixed', it means say nothing. >If you need to make code that isn't internationalized and you want a hack, >call the setlocale(,"") in main() if the desired program. It will be broken for locales wich char width > 8bits. Proper thing is to call non-standard startup_setlocale() which check char size not exceeds 8bit. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 18:20:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA02449 for hackers-outgoing; Mon, 16 Oct 1995 18:20:25 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA02442 for ; Mon, 16 Oct 1995 18:20:22 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA25982; Mon, 16 Oct 1995 18:15:16 -0700 From: Terry Lambert Message-Id: <199510170115.SAA25982@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 18:15:15 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, kaleb@x.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 17, 95 02:23:38 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6415 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >Well, fix the C locale's undefined behaviour to be the same as the defined > >8859-1 behaviour. Problem solved. > > It seems that you miss the point here. Most harmful are macros such > as isprint(), islower()/isupper(), isalpha(), ispunct(), etc. > all of them are different for various 8bit charsets, f.e. > isalhpa(8859-1) != isalpha(KOI8-R). > If you stuck with one particular version, f.e. 8859-1, is*() > functions will return incorrect values for any other charset used > screwing your screen and keyboard input. I.e. 8859-1 toupper() can > produce very strange char for KOI8-R input. Or 8859-1 checking > input for ispunct() can allow very strange KOI8-R chars sneak in. > Or 8859-1 isalhpa() for output can print very strange chars > for KOI8-R, etc. Don't forget, I use KOI8-R only for example, > you can find some 8859-* font to substitute instead of this name. I can *potentially* see ispunct() (though I can't think of any concrete examples off my head; maybe in -9?), and the collating sequence is a problem. But this is a problem regardless. If the code isn't internationalized, it isn't internationalized, and anything you do to pretend it is without actually fixing the code is a kludge. The correct thing to do is to call setlocale() in the source. You could, if you wanted a "quick fix", use setlocale(,""), per your crt0.o hack. > >Fix the C locale, not the crt0.o. Then, as time permits, fix the locale > >unaware code. > > What do you mean by fixing C locale exactly? Make it act like an 8859-x locale. That means 8859-1, with the exception of collation sequence and (I still don't have an example for this one) ispunct(). If you care about collation sequence, then you'll internationalize your code. > >As long as the characters are passed through unadulterated, there is > >no difference for n == 1 and n != 1 in the non-setlocale() called case, > >which is the issue. If the damn thing wasn't being called and the > >C locale were correctly defined for "undefined" code points, then there > >would not be a problem. > > What you mean by unaltered? They are unaltered, but they belongs > to different classes in different charsets, real separator is > is*() functions. Unadulterated. Unchanged by the interface without the knowledge of the user or his explicit approval of the change. The difference is that the 0x40-0x5f,0x60-0x7f changes for case conversion are universally applicable across all 8859-x sets. Only certain rarely used aspects of the default locale are affected, and those would require explicit use of the setlocale(0 to operate correctly in any case. > >Calling "setlocale()" for an otherwise non-internationalized program is > >a big mistake, and just compounds the C locale mistake. Correct the > >right code. > > BTW, when C program is known 8bit clean, what I and my users > want from FreeBSD is proper interaction with russian language. Then use 8859-5 character encoding. The only deficiency re: KOI8 is that it doesn't match existing data you already have on disk. Or explicitly call setlocale(). If the code is in fact 8 bit clean, then very little is left that needs to be done to make it internationalized, at least in the XPG/3 sense (runic encoding was introduced in XPG/4). > It means that > 1) all is*() macros must be correct for russian charset (LC_CTYPE). This will work for 8859-5. Characters that are completely bogus will fail, but they'd fail anyway. Don't mix locales on the same storage media or go to Unicode name storage and the problem will go away. Or explicitly call setlocale(), as recommentd in the X/Open Portability Guide. > 2) strftime must return national data (LC_TIME). Explicitly call setlocale(). > 3) National sorting must works (LC_COLLATE). Explicitly call setlocale(). Your sorts probably aren't using locale information anyway if you aren't calling setlocale(), so nothing has really changed between your hack and the non-hack (standards conformant) case on this one. > Now all that goals are reached by 'setenv ENABLE_STARTUP_LOCALE' > and without any program modifications. It is especially essential when > program isn't FreeBSD native but comes from 3rd party, i.e. > ports area. Moreover, they can be reached on any remote system > too, includes freefall f.e. There is an implied program modification of main (as opposed to _main). The correct way to make a program locale sensitive is to change its code so that it is locale sensitive. > The same words are true for 8859-1 users too, not only for KOI8-R > users. KOI8 is a peculiar locale in that it doesn't follow the 8859-x rules like it should. Like EBCDIC, it needs to die in the long term. On the other hand, if you desperately need to be able to use it, even given its implicit limitations, then you can do so. If you use locale aware code. > Maybe this functionality isn't kosher but you even can't imagine how > it is useful. > > If you know "proper way" to do things and keeps this goals non-broken too, > I am all ears. This whole issue is very similar to the problems that were involved in going to an unmapped page 0, causing NULL dereferences to SIGSEGV. In the short term, you lost functionality because you couldn't run some programs you used to be able to run. In the locale case, you lose the ability to run 8 bit clean code as if it had been properly internationalized, while making other code plain miserable to use. Without the imlied setlocale() call in crt0.o, there is an immediate benefit of ~1.1M of disk in static binaries (from Kaleb's numbers), and the code that isn't internationalized becomes readily apparent. Just as the code that dereferenced NULL became readily apparent when page 0 was unmapped. Setting an "undefined" equality with 8859-1 preserves 8 bit clean operability in the majority of cases, and in the others, the only way that they could have been able to get the functionality was to have partially internationalized their code (you can't get at the altered collation sequence without some knowledge of internationalization implicit in the code). The net effect is that more code gets internationalized correctly, which is in everyone's best interests and increases the code portability instead of tying the users to FreeBSD. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 18:25:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA02575 for hackers-outgoing; Mon, 16 Oct 1995 18:25:49 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA02569 for ; Mon, 16 Oct 1995 18:25:44 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA26017; Mon, 16 Oct 1995 18:20:35 -0700 From: Terry Lambert Message-Id: <199510170120.SAA26017@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 18:20:35 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.freebsd.org, kaleb@x.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 17, 95 02:40:38 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1873 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >This is valid for all 8859-x display/input systems, since the reuse of > >the code points are not transformed by this (8859-x does not encode > >characters in those locations). > > You consider one very simple case (isprint/iscontrol only) and think > that it is a proof. What you can say about ispunct() f.e.? > It is clearly differ into 8859-1 and 8859-5 f.e., islower/isupper differs > too. tolower/toupper differs too. Even isalpha differs. What did I say before about lobbying international standards bodies to replace 8859-5? I don't know if I buy the [is,to][upper,lower] distinctions. I think they are mainly for undefined code points, and getting the wrong result in an undefined are is not a problem. > >The only potentially incorrect behaviour is on blanks not being interpreted > >as blanks. If you want a blank, you shouldn't be using some wild code > >point other than 0x20 anyway. You get what you deserve. > > Well, isspace differs too. Space isn't 0x20 in 8859-5? Tab, LF, CR aren't the same? > >The problems you will encounter in this circumstance are all *very* > >specific to cases where a single file system is being used by multiple > >nationalities of clients. > > No it is different problem. By setting LANG for something != 8859-1 > (for programs that understands it) I assume that programs which > not understands it still works right. > If they are strict ASCII, I automatically protected from any > unwanted effects. If they are 8859-1 I need to classify > various unwanted effects for each != 8859-1 charset as > 'default undefined behaviour'. I agree. And this is precisely the problem with the crt0.o/setlocale() hack. You are implicitly removing the protection from unwanted effects. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 18:27:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA02631 for hackers-outgoing; Mon, 16 Oct 1995 18:27:39 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA02621 for ; Mon, 16 Oct 1995 18:27:34 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id LAA17511; Tue, 17 Oct 1995 11:23:55 +1000 Date: Tue, 17 Oct 1995 11:23:55 +1000 From: Bruce Evans Message-Id: <199510170123.LAA17511@godzilla.zeta.org.au> To: bde@zeta.org.au, mark@grondar.za Subject: Re: Creating a /dev/random Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk I wrote: >>> To avoid this, use the existing buffer `zbuf', which is freed correctly. >>> There is no need for another variable - local variables are per process. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> Perhaps `zbuf' should be renamed `buf'. >>I don't understand something here - what happens if the one process is >>reading both /dev/zero and /dev/random? will the two not then try to >>share buf/zbuf and screw up? >See above Oops, I misread `one process'. Well, one process can't be in the kernel twice. Bruce From owner-freebsd-hackers Mon Oct 16 18:37:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA02895 for hackers-outgoing; Mon, 16 Oct 1995 18:37:49 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA02890 for ; Mon, 16 Oct 1995 18:37:46 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA26056; Mon, 16 Oct 1995 18:32:36 -0700 From: Terry Lambert Message-Id: <199510170132.SAA26056@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 18:32:36 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, hackers@freefall.freebsd.org, j@uriah.heep.sax.de, kaleb@x.org, phk@critter.tfs.com In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 17, 95 02:57:56 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2311 Sender: owner-hackers@FreeBSD.org Precedence: bulk > Now you vote for solution which is simple subcase of my crt0 hack: > > setlocale(LC_ALL, ""); /* my */ > > changed to > > setlocale(LC_ALL, "lt_LN.ISO_8859-1"); /* your */ > > Since your variant is static (and my is adjusted to current LANG), > you don't need even such call and can patch default table directly. The difference is, I'm not making a call. Any you can "patch" a binary by looking for the locale specific table's symbols in the binary and modifying them. Or you can patch the source and make the code locale aware. Like you should be doing in the first place. > For LANG = 8859-1 both variants are equal, but for LANG != 8859-1 you > give some strange values calling them 'default' and I give > full correct ctype/time/collate table. If we take the American-specific ASCII C locale per POSIX as opposed to the 8859-1 specific ISO C locale, we simply increase the "incorrect" behaviour. The point of using the POSIX C locale as default is to inconvenience people, nagging them into makeing their code locale aware. Technically, ISO C locale permits removal of the nagging for ISO8859-1, as well as 7 bit ASCII, which is understandable because of who are and aren't ISO member standards bodies (US, Western European, etc.) But this does not invalidate the reasons for nagging in the first place. And Western European nations (other than English speakers that can get by with ASCII) don't get their preferred collation sequence either. Just like you. Germany has two sequences (dictionary and telephone directory order), neither of which are satisfied by a halfway job of internationalization. I think you would be hard put to find a program that did strcmp() for sorting in any case, so it's likely that anything that was collation sequence sensitive under your hack, would in fact have been written to call setlocale() specifically in the first place. The point is to stay within the bounds of the standards. We have both precedent and standards recognition for 8859-1 in the C locale. Yes, this means that code that has not been internationalized will annoy you until you fix it. With due respect, this is a *feature*. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 18:44:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA03043 for hackers-outgoing; Mon, 16 Oct 1995 18:44:08 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA03038 for ; Mon, 16 Oct 1995 18:44:04 -0700 Received: by sovcom.kiae.su id AA06088 (5.65.kiae-1 ); Tue, 17 Oct 1995 04:31:11 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 04:31:10 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id EAA00837 for kaleb@x.org; Tue, 17 Oct 1995 04:25:24 +0300 To: "Kaleb S. KEITHLEY" Cc: hackers@freebsd.org References: <199510170105.VAA25559@exalt.x.org> In-Reply-To: <199510170105.VAA25559@exalt.x.org>; from "Kaleb S. KEITHLEY" at Mon, 16 Oct 1995 21:05:24 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 04:25:24 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 49 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1986 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510170105.VAA25559@exalt.x.org> Kaleb S. KEITHLEY writes: >> I know. And it is so when you don't have LANG or your char width > 8bits. >> When you have LANG and your char width <= 8bits and you have >> ENABLE_STARTUP_LOCALE variable set, lets call this case as >> "ANSI extention". As you can see, this extention is well-controlled >> by ENABLE_STARTUP_LOCALE. >And this marvelous "extension" breaks programs, as you've found with >the XFree86 xterm. Well, shure, it seems that you not expect that propogating code table to 8859-1 BREAKS XTERM in the same way! Because when LANG set to 8859-1 our cases are equal! >> Most of my agrument isn't premise but different behaviour of all >> is*() macros for different charsets. What 8859-1 program treats >> as isalpha isn't isalpha in other charset, for both input/output. >> When program bound its input/output by is*() macros, it leads >> into big trouble into your variant. >I claim this is a non-issue. Terry claims it's expected behavior. Please >provide an example or other proof that this is not the case. Pretty simple, here some example of code: do { *s++ = getchar(); } while (!ispunct(*s)); When 8859-1 is set it stops on D7 and it will be right. When 8859-5 is set is stops on D7 too, but D7 is letter. >Because your way of fixing is in violation of ANSI/POSIX/ISO. Well, it isn't only "my" way, I saw the same behavior in Xenix internationalization f.e. :-) I agree now that it can't be default case, so I withdraw my proposal to change ENABLE to DISABLE. >When it's active it breaks correct programs. When it's inactive it isn't It breaks no more than table propopgating, just right in the same way. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 18:46:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA03146 for hackers-outgoing; Mon, 16 Oct 1995 18:46:56 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA03134 for ; Mon, 16 Oct 1995 18:46:53 -0700 Received: from exalt.x.org by expo.x.org id AA11461; Mon, 16 Oct 95 21:46:21 -0400 Received: from localhost by exalt.x.org id VAA25626; Mon, 16 Oct 1995 21:46:15 -0400 Message-Id: <199510170146.VAA25626@exalt.x.org> To: ache@astral.msk.su Cc: hackers@freefall.FreeBSD.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Tue, 17 Oct 1995 04:09:48 EST. Organization: X Consortium Date: Mon, 16 Oct 1995 21:46:15 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > In message <199510170051.RAA25909@phaeton.artisoft.com> Terry Lambert > writes: > > >For one, my "hack" meets the definition of the ISO ratification of X3J11 > >and at the same time conforms to ISO 8859-x character set rules. > > >It works for all ISO8859-x users, not just ISO8859-1. > > >The difference is wherein the character code points are set based on > >columnar location. This was, in fact, one of the stated design goals > >of the 8859-x standards. > > Well, lets consider D7 char from 8859-1 exactly: is it > ispunct() too f.e, in 8859-5? > Lets consider DF char exactly, is it islower() too f.e. in 8859-5? I thought we already established that in the C locale ANSI stipulates islower/tolower/isupper/toupper only apply to 0x20<=c<=0x7e? > BTW, why we even forced to be strictly in 8859 bounds? Why another > charset with lower half equal to ASCII can't live too? No one is saying you can't. But the use of 8859-5 over e.g. KOI8-R does seem to have some advantages, for the reasons Terry pointed out. > >The one real issue is the collating sequence. This is a non-issue for > >"7-bit-ASCII-first" sort orders. They will be correct. It *IS* an > >issue for "non-internationalized code pretending to be internationalized". > > >I have absolutely no sympathy for such code; it should be fixed. > > Well, it should be fixed by *WHOM* and *WHEN*? As you don't have sympathy, > maybe you take this task as contacting to authors, fixing, etc. > for each such program? Some of such programs needed right now, > and I can't say to my users that they 'should be fixed', it means > say nothing. I don't know how well "free" translates into Russian. On this side of the pond we have a saying: There Ain't No Such Thing As A Free Lunch, or TANSTAAFL for short. I said this to you in private email, now I'll say it here on hackers. There is a price for using free software. If it doesn't work for you, the burden is on you to fix it. Your hack to crt0.o as a means to avoid fixing the broken software you're using is just that, a hack. A big hairy green monster of a hack. I don't want hacks in the OS I'm using. You fix the software you're using. When you fix it make sure you send the fix to the author. With any luck some day you won't be forced to fix it again every time there's a new release. > >If you need to make code that isn't internationalized and you want a hack, > >call the setlocale(,"") in main() if the desired program. > > It will be broken for locales wich char width > 8bits. I don't believe this, and I explained why in a previous email. > Proper thing is to call non-standard startup_setlocale() which > check char size not exceeds 8bit. Can you even begin to imagine what would happen if, e.g. Microsoft or Sun said this is what you have to do? -- Kaleb From owner-freebsd-hackers Mon Oct 16 19:00:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA03438 for hackers-outgoing; Mon, 16 Oct 1995 19:00:30 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA03433 for ; Mon, 16 Oct 1995 19:00:26 -0700 Received: from exalt.x.org by expo.x.org id AA11674; Mon, 16 Oct 95 21:59:54 -0400 Received: from localhost by exalt.x.org id VAA25639; Mon, 16 Oct 1995 21:59:53 -0400 Message-Id: <199510170159.VAA25639@exalt.x.org> To: ache@astral.msk.su Cc: hackers@freefall.FreeBSD.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Tue, 17 Oct 1995 04:25:24 EST. Organization: X Consortium Date: Mon, 16 Oct 1995 21:59:52 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > In message <199510170105.VAA25559@exalt.x.org> Kaleb S. KEITHLEY > writes: > > >> I know. And it is so when you don't have LANG or your char width > 8bits. > >> When you have LANG and your char width <= 8bits and you have > >> ENABLE_STARTUP_LOCALE variable set, lets call this case as > >> "ANSI extention". As you can see, this extention is well-controlled > >> by ENABLE_STARTUP_LOCALE. > > >And this marvelous "extension" breaks programs, as you've found with > >the XFree86 xterm. > > Well, shure, it seems that you not expect that propogating code > table to 8859-1 BREAKS XTERM in the same way! Because when LANG > set to 8859-1 our cases are equal! I don't believe this. If this were true then all the XFree86 users in Europe would be screaming bloody murder; probably even more than they were prior to XFree86 3.1.1, when the i18n aware xterm was introduced. -- Kaleb From owner-freebsd-hackers Mon Oct 16 19:05:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA03619 for hackers-outgoing; Mon, 16 Oct 1995 19:05:54 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA03597 for ; Mon, 16 Oct 1995 19:05:50 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA26131; Mon, 16 Oct 1995 19:00:48 -0700 From: Terry Lambert Message-Id: <199510170200.TAA26131@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 19:00:48 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, kaleb@x.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 17, 95 04:09:48 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4985 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >For one, my "hack" meets the definition of the ISO ratification of X3J11 > >and at the same time conforms to ISO 8859-x character set rules. > > >It works for all ISO8859-x users, not just ISO8859-1. > > >The difference is wherein the character code points are set based on > >columnar location. This was, in fact, one of the stated design goals > >of the 8859-x standards. > > Well, lets consider D7 char from 8859-1 exactly: is it > ispunct() too f.e, in 8859-5? > Lets consider DF char exactly, is it islower() too f.e. in 8859-5? 8859-5 is broken. You admit this by using KOI-8 instead, yet you want to use it as an example? Let me point out that ispunct() is useful only in internationalized code; make a choice: is your program to which your hack applies internationalized or not? If it is, then your hack doesn't apply. If it isn't, then your ispunct() argument doesn't apply. The 8859-5 character set violates several design principles inherent in the 8859-x character set family. I will not appologize for that; the people who designed the character set were not my countrymen; they only ratified what the accepted standards body in charge of that set in their own country put forth. I remember the long argument on whether they had the right to make standards or not that boiled down to decision at the time being "not very representative", to be polite. I can dig up the references, since I have been saving everything I've seen of interest on internationalization on this list and on the net for forever. If this is the general consensus, then fine: lobby your standards body and replace 8859-5. But don't complain that compromises should be made because both 8859-5 and KOI-8 violate 8859-x design principles and that ISO arguably expanded the ISO C to include 8859-1. The point remains that this inconvenience is your incentive to fix the code and properly internationalize it. > BTW, why we even forced to be strictly in 8859 bounds? Why another > charset with lower half equal to ASCII can't live too? Because of precedent and because of ISO. If you can give us a competing standard to choose from, fine. Right now, we have XPG3/XPG4 and POSIX vs. ICO C locale definitions. If you can show a standard that doesn't point at the 'C' locale, then fine. If you can show a standard that doesn't conflict with linear indexing of Unicode or ISO10646 page 0 (both of which specify 0x0000-0x00ff as ISO 8859-1), fine. > >The one real issue is the collating sequence. This is a non-issue for > >"7-bit-ASCII-first" sort orders. They will be correct. It *IS* an > >issue for "non-internationalized code pretending to be internationalized". > > > >I have absolutely no sympathy for such code; it should be fixed. > > Well, it should be fixed by *WHOM* and *WHEN*? As you don't have sympathy, > maybe you take this task as contacting to authors, fixing, etc. > for each such program? Some of such programs needed right now, > and I can't say to my users that they 'should be fixed', it means > say nothing. You're welcome to run with a non-standard extention to ctr0.o, or better as a C library virtual base calss initializer using CTOR/DTOR magic to put it in your own C library and not everywhere (you could even default the locale to KOI-* in that case). It should be fixed by the people who are annoyed by it not being fixed. That means the end users, the people the end users complain to, and then (eventually) the authors of the code who get complained to. Just like Sun Microsystems. You annoy them until they fix it. > >If you need to make code that isn't internationalized and you want a hack, > >call the setlocale(,"") in main() if the desired program. > > It will be broken for locales wich char width > 8bits. > Proper thing is to call non-standard startup_setlocale() which > check char size not exceeds 8bit. Or to specify XPG/3 instead of XPG/4. XPG/4 marked the introduction of the heinously bogus runic encoding methods and thus wide character process encoding. If you specify XPG/3, then you will be fine. If you are worried about CJK and other "large glyph set" character sets (ie: won't fit in 0x00-0xff), they have ISO-2022 locales and aren't very interested in XPG/4 and/or Unicode/ISO10646 anyway because of the inability to build multinationalized applications for multilingual processing in the unified character sets. That doesn't mean the Win95 and WinNT won't cause Unicode to take over the world whether anyone likes it or not. It will take over the world. In the end, the end user, not the programmers make the decisions. All the end user cares about is that it works, not about the amount of effort programmers have to expend to make it work. Arguing with large glyph set internationalization using XPG/4 mechanisms as an example to the contrary is non-productive. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 19:10:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA03786 for hackers-outgoing; Mon, 16 Oct 1995 19:10:40 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA03777 for ; Mon, 16 Oct 1995 19:10:31 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA26154; Mon, 16 Oct 1995 19:04:08 -0700 From: Terry Lambert Message-Id: <199510170204.TAA26154@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Mon, 16 Oct 1995 19:04:08 -0700 (MST) Cc: dawes@rf900.physics.usyd.edu.au, kaleb@x.org, ache@astral.msk.su, hackers@freefall.freebsd.org In-Reply-To: <199510162300.AAA28238@keltia.freenix.fr> from "Ollivier Robert" at Oct 17, 95 00:00:45 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 790 Sender: owner-hackers@FreeBSD.org Precedence: bulk > I have the following by default in my environment : > > LANG=fr_FR.ISO_8859-1 > LC_CTYPE=iso_8859_1 > > As soon as I switch LC_CTYPE to fr_FR.ISO_8859-1, all xterms started from > this terminal will dump core (well, they won't because xterm is setuid > root), each time. The signal is SEGV. Your xterm is improperly pretending to be internationalized. It's pretending because there is bogus code in crt0.o that causes it to call setlocale() when XPG/3 and XPG/4 both say it shouldn't. Either don't try to run in an international environment... or use an xterm clone from contrib instead of xterm that really has been internationalized. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 19:13:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA03900 for hackers-outgoing; Mon, 16 Oct 1995 19:13:59 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA03895 for ; Mon, 16 Oct 1995 19:13:54 -0700 Received: by sovcom.kiae.su id AA08511 (5.65.kiae-1 ); Tue, 17 Oct 1995 05:06:37 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 05:06:37 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id FAA00981; Tue, 17 Oct 1995 05:05:20 +0300 To: Terry Lambert Cc: hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, kaleb@x.org References: <199510170115.SAA25982@phaeton.artisoft.com> In-Reply-To: <199510170115.SAA25982@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 18:15:15 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 05:05:20 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 117 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 4654 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510170115.SAA25982@phaeton.artisoft.com> Terry Lambert writes: >I can *potentially* see ispunct() (though I can't think of any >concrete examples off my head; maybe in -9?), and the collating >sequence is a problem. Not only ispunct(), if you dig deeper, just put all 8859-* charset in front of you and see how they are really differ. >But this is a problem regardless. If the code isn't internationalized, >it isn't internationalized, and anything you do to pretend it is without >actually fixing the code is a kludge. ASCII default table is the way to avoid pitfails because it restricts all operations to 7bit (disallows all 8bit stuff). It is one of the reasons why I vote for ASCII. >The correct thing to do is to call setlocale() in the source. You could, >if you wanted a "quick fix", use setlocale(,""), per your crt0.o hack. Calling setlocale() is impossible for 8bit clean programs if they are not aware of multi-byte characters. I use special version of setlocale (statrtup_setlocale) in my crt0 hack which is restricted to <=8bit char sizes only. >If you care about collation sequence, then you'll internationalize your >code. Well, but how's about strftime? It isn't supposed to call setlocale before or what? I saw several places in our sources when strftime was called without any setlocale, does all of them need to be fixed? >Then use 8859-5 character encoding. The only deficiency re: KOI8 is >that it doesn't match existing data you already have on disk. 8859-5 not goes in any case. It not my decision but whole russian users community (SUUG - Soviet Unix Users Group). >> It means that >> 1) all is*() macros must be correct for russian charset (LC_CTYPE). >This will work for 8859-5. Characters that are completely bogus will >fail, but they'd fail anyway. Characters that are completely bogus in 8859-1 is valid letters in 8859-5. :-) >> 2) strftime must return national data (LC_TIME). >Explicitly call setlocale(). See above. >KOI8 is a peculiar locale in that it doesn't follow the 8859-x rules >like it should. Like EBCDIC, it needs to die in the long term. On And WHY IT SHOULD DO anything? It is EXISTEN CODE TABLE and LOCALES must be adopted for it and not vice versa. I promise you that it never dies in nearest 20-40 years, its population grows whith each new Internet user. >> Maybe this functionality isn't kosher but you even can't imagine how >> it is useful. >This whole issue is very similar to the problems that were involved in >going to an unmapped page 0, causing NULL dereferences to SIGSEGV. In >the short term, you lost functionality because you couldn't run some >programs you used to be able to run. It isn't correct example for this case. >In the locale case, you lose the ability to run 8 bit clean code as if >it had been properly internationalized, while making other code plain >miserable to use. >Without the imlied setlocale() call in crt0.o, there is an immediate >benefit of ~1.1M of disk in static binaries (from Kaleb's numbers), and It is less than this value, if you want, I'll tell exactly. >the code that isn't internationalized becomes readily apparent. Just >as the code that dereferenced NULL became readily apparent when page 0 >was unmapped. *WHO* will internationalize such code? >Setting an "undefined" equality with 8859-1 preserves 8 bit clean >operability in the majority of cases, and in the others, the only >way that they could have been able to get the functionality was to >have partially internationalized their code (you can't get at the >altered collation sequence without some knowledge of internationalization >implicit in the code). >The net effect is that more code gets internationalized correctly, which >is in everyone's best interests and increases the code portability instead >of tying the users to FreeBSD. Well, as I already say only thing that makes me stay against propogating was non-matched is*() stuff. From your words I assume that you simple do nothing with it and marks incompatibles as 'improper i18n in any case', well, it is the way :-) BTW, I assume to keep my hack in the state as is, because too many russian users already relays on it. I consider possibilites to reduce bloat by ways that Bruce point, i.e. libc ctype cleanup and two different startup_locale stubs for real ctype and for fake. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 19:15:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA04018 for hackers-outgoing; Mon, 16 Oct 1995 19:15:57 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA04013 for ; Mon, 16 Oct 1995 19:15:53 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA26181; Mon, 16 Oct 1995 19:10:53 -0700 From: Terry Lambert Message-Id: <199510170210.TAA26181@phaeton.artisoft.com> Subject: Re: getdtablesize() broken? To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Mon, 16 Oct 1995 19:10:53 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.freebsd.org In-Reply-To: <199510161939.PAA08113@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 16, 95 03:39:29 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1754 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >Poll, anyone? > > >Poll is inferior to select, > > Debatable. Not. 8-). > >both because of the 10ms limit on timeout > >resoloution > > Man pages only say that if the host does not support millisecond > accuracy then the value is rounded up to the nearest legal value > available. 10ms is the argument resoloution. On Solaris, it's 10ms, while select() is till 4uS. select() wins. 8-). > That hasn't been my experience. poll(0, NULL, 10000); waits 10 seconds > on SunOS, all SVR4-en I have here, HPUX, and AIX; however Digital Unix's > poll looses. In fact in SVR4 select(3) is implemented using poll(2). That's a bug in SVR4. SVR4 is broken and bogus in many, many ways. That's why this is "FreeBSD" instead of "FreeSVR4". 8-). Dec's poll() is based on the Mentat streams code. I'm suprised they didn't roll in the fixed Robert Withrow and I put in when writing the Pathworks for VMS (NetWare) server. I had to fix that and several other things, including some DEC Bliss code, to get a working process model. I believe the SAP thread used a poll with a 0 timeout. The final code used Timer Queue Entry AST's, but the effect was the same. > In theory poll could be more efficient because there's less bit > twiddling to do and unless you're polling thousands of files poll > needs to transfer far less data to the kernel address space. Back > in the days of 1.1.5.1 I started to look at what it would take to > add poll. Maybe I'll look again. I agree that it could, though I'd want a timeval struct instead of an integer time value implicitly limited to a 10ms resoloution by its units. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 19:29:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA04428 for hackers-outgoing; Mon, 16 Oct 1995 19:29:01 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA04423 for ; Mon, 16 Oct 1995 19:28:55 -0700 Received: by sovcom.kiae.su id AA10078 (5.65.kiae-1 ); Tue, 17 Oct 1995 05:28:36 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 05:28:36 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id FAA01047; Tue, 17 Oct 1995 05:13:56 +0300 To: "Kaleb S. KEITHLEY" Cc: hackers@freefall.FreeBSD.org References: <199510170159.VAA25639@exalt.x.org> In-Reply-To: <199510170159.VAA25639@exalt.x.org>; from "Kaleb S. KEITHLEY" at Mon, 16 Oct 1995 21:59:52 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 05:13:55 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 34 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1447 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510170159.VAA25639@exalt.x.org> Kaleb S. KEITHLEY writes: >> In message <199510170105.VAA25559@exalt.x.org> Kaleb S. KEITHLEY >> writes: >> >> >> I know. And it is so when you don't have LANG or your char width > 8bits. >> >> When you have LANG and your char width <= 8bits and you have >> >> ENABLE_STARTUP_LOCALE variable set, lets call this case as >> >> "ANSI extention". As you can see, this extention is well-controlled >> >> by ENABLE_STARTUP_LOCALE. >> >> >And this marvelous "extension" breaks programs, as you've found with >> >the XFree86 xterm. >> >> Well, shure, it seems that you not expect that propogating code >> table to 8859-1 BREAKS XTERM in the same way! Because when LANG >> set to 8859-1 our cases are equal! >I don't believe this. If this were true then all the XFree86 users in >Europe would be screaming bloody murder; probably even more than they >were prior to XFree86 3.1.1, when the i18n aware xterm was introduced. startup_locale does nothing expect loading of tables. The same tables as in your case. But internal ctype structure is very different comparing SVR4 f.e. It is play role here. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 19:29:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA04450 for hackers-outgoing; Mon, 16 Oct 1995 19:29:08 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA04436 for ; Mon, 16 Oct 1995 19:29:04 -0700 Received: by sovcom.kiae.su id AA10080 (5.65.kiae-1 ); Tue, 17 Oct 1995 05:28:37 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 05:28:37 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id FAA01077; Tue, 17 Oct 1995 05:27:12 +0300 To: Terry Lambert Cc: hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, kaleb@x.org References: <199510170200.TAA26131@phaeton.artisoft.com> In-Reply-To: <199510170200.TAA26131@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 19:00:48 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 05:27:12 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 60 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2944 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510170200.TAA26131@phaeton.artisoft.com> Terry Lambert writes: >> >For one, my "hack" meets the definition of the ISO ratification of X3J11 >> >and at the same time conforms to ISO 8859-x character set rules. >> >> >It works for all ISO8859-x users, not just ISO8859-1. >> >> >The difference is wherein the character code points are set based on >> >columnar location. This was, in fact, one of the stated design goals >> >of the 8859-x standards. >> >> Well, lets consider D7 char from 8859-1 exactly: is it >> ispunct() too f.e, in 8859-5? >> Lets consider DF char exactly, is it islower() too f.e. in 8859-5? >8859-5 is broken. You admit this by using KOI-8 instead, yet you want >to use it as an example? The only reason that I reference to 8859-5 is that I remember it well :-) If you want, I can dig out another 8859 incompatible font, it simple takes longer time. >> >If you need to make code that isn't internationalized and you want a hack, >> >call the setlocale(,"") in main() if the desired program. >> >> It will be broken for locales wich char width > 8bits. >> Proper thing is to call non-standard startup_setlocale() which >> check char size not exceeds 8bit. >Or to specify XPG/3 instead of XPG/4. XPG/4 marked the introduction of >the heinously bogus runic encoding methods and thus wide character process >encoding. If you specify XPG/3, then you will be fine. Well, I plan to go and fix all current ctype-aware FreeBSD sources to call setlocale() first. I can remove my hack only after this step will be done. So, I need to know exactly, what XPG we plan to support. If we don't plan to support runic encoding, we can reduce current bloat much more by removing runic. In early days I plan to see strict 8bit locale into FreeBSD but Garrett was who introduce runic locale. I prefer not use runic, of course. >If you are worried about CJK and other "large glyph set" character sets >(ie: won't fit in 0x00-0xff), they have ISO-2022 locales and aren't >very interested in XPG/4 and/or Unicode/ISO10646 anyway because of the >inability to build multinationalized applications for multilingual >processing in the unified character sets. That doesn't mean the Win95 >and WinNT won't cause Unicode to take over the world whether anyone >likes it or not. It will take over the world. In the end, the end >user, not the programmers make the decisions. All the end user cares >about is that it works, not about the amount of effort programmers >have to expend to make it work. Arguing with large glyph set >internationalization using XPG/4 mechanisms as an example to the >contrary is non-productive. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 19:43:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA05154 for hackers-outgoing; Mon, 16 Oct 1995 19:43:59 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA05146 for ; Mon, 16 Oct 1995 19:43:50 -0700 Received: by sovcom.kiae.su id AA10937 (5.65.kiae-1 ); Tue, 17 Oct 1995 05:38:42 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 05:38:42 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id FAA01170; Tue, 17 Oct 1995 05:37:53 +0300 To: "Kaleb S. KEITHLEY" Cc: hackers@freefall.FreeBSD.org References: <199510170146.VAA25626@exalt.x.org> In-Reply-To: <199510170146.VAA25626@exalt.x.org>; from "Kaleb S. KEITHLEY" at Mon, 16 Oct 1995 21:46:15 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 05:37:52 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 27 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1055 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510170146.VAA25626@exalt.x.org> Kaleb S. KEITHLEY writes: >I thought we already established that in the C locale ANSI stipulates >islower/tolower/isupper/toupper only apply to 0x20<=c<=0x7e? Well, Terry do you mean propogation to _full_ 8859-1 or the same _reduced_ variant as Kaleb means? And hows about ispunct (its differ)? >> >If you need to make code that isn't internationalized and you want a hack, >> >call the setlocale(,"") in main() if the desired program. >> >> It will be broken for locales wich char width > 8bits. >I don't believe this, and I explained why in a previous email. Well, currently we have XPG/4 into libc and even some data to support it, so you can believe. Are we need a vote to cut down XPG/4 to XPG/3? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 19:44:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA05200 for hackers-outgoing; Mon, 16 Oct 1995 19:44:50 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA05192 for ; Mon, 16 Oct 1995 19:44:46 -0700 Received: by sovcom.kiae.su id AA10598 (5.65.kiae-1 ); Tue, 17 Oct 1995 05:33:33 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 05:33:33 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id FAA01146; Tue, 17 Oct 1995 05:32:39 +0300 To: Ollivier Robert , Terry Lambert Cc: dawes@rf900.physics.usyd.edu.au, hackers@freefall.freebsd.org, kaleb@x.org References: <199510170204.TAA26154@phaeton.artisoft.com> In-Reply-To: <199510170204.TAA26154@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 19:04:08 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 05:32:39 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 25 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 992 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510170204.TAA26154@phaeton.artisoft.com> Terry Lambert writes: >> I have the following by default in my environment : >> >> LANG=fr_FR.ISO_8859-1 >> LC_CTYPE=iso_8859_1 >> >> As soon as I switch LC_CTYPE to fr_FR.ISO_8859-1, all xterms started from >> this terminal will dump core (well, they won't because xterm is setuid >> root), each time. The signal is SEGV. >Your xterm is improperly pretending to be internationalized. It's >pretending because there is bogus code in crt0.o that causes it to >call setlocale() when XPG/3 and XPG/4 both say it shouldn't. Be shure that your propogating cause the same effect on xterm as my hack (the same code table loaded). -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 19:45:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA05228 for hackers-outgoing; Mon, 16 Oct 1995 19:45:03 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA05214 for ; Mon, 16 Oct 1995 19:44:57 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA26264; Mon, 16 Oct 1995 19:39:54 -0700 From: Terry Lambert Message-Id: <199510170239.TAA26264@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 19:39:54 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, kaleb@x.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 17, 95 05:05:20 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7943 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >I can *potentially* see ispunct() (though I can't think of any > >concrete examples off my head; maybe in -9?), and the collating > >sequence is a problem. > > Not only ispunct(), if you dig deeper, just put all 8859-* > charset in front of you and see how they are really differ. All my good standards documents are at home. 8-(. > >But this is a problem regardless. If the code isn't internationalized, > >it isn't internationalized, and anything you do to pretend it is without > >actually fixing the code is a kludge. > > ASCII default table is the way to avoid pitfails because it restricts > all operations to 7bit (disallows all 8bit stuff). It is one of the > reasons why I vote for ASCII. It doesn't avoid the pitfalls. A "sort" that isn't localized will fall over silently when fed non-ASCII data, just like data in the wrong locale. > >The correct thing to do is to call setlocale() in the source. You could, > >if you wanted a "quick fix", use setlocale(,""), per your crt0.o hack. > > Calling setlocale() is impossible for 8bit clean programs if they > are not aware of multi-byte characters. I use special version of > setlocale (statrtup_setlocale) in my crt0 hack which is restricted to <=8bit > char sizes only. BS. Read XPG/3, which doesn't know about multibyte characters, yet defines setlocale(). It's true that calling an XPG/4 setlocale() in an 8-bit clean, multibyte unaware program in a runic encoded/multibyte locale will fail. The soloution is to fix the program. > >If you care about collation sequence, then you'll internationalize your > >code. > > Well, but how's about strftime? It isn't supposed to call setlocale before > or what? I saw several places in our sources when strftime was called > without any setlocale, does all of them need to be fixed? Yes. If they use locale data which can not be defaulted per XPG3/XPG4, the code needs to be fixed. > >Then use 8859-5 character encoding. The only deficiency re: KOI8 is > >that it doesn't match existing data you already have on disk. > > 8859-5 not goes in any case. It not my decision but whole russian users > community (SUUG - Soviet Unix Users Group). Then have then replace it by sending a representative to the national standards body that sends their representative to ISO. But follow the 8859-x formulation rules this time. I think the major problem you have with 8859-5 is installed code base, and that's not an excuse (or American generated code would not know about locale at all: our installed base is 7 bit ASCII, thank you). > >> It means that > >> 1) all is*() macros must be correct for russian charset (LC_CTYPE). > > >This will work for 8859-5. Characters that are completely bogus will > >fail, but they'd fail anyway. > > Characters that are completely bogus in 8859-1 is valid letters > in 8859-5. :-) Guess you better call setlocale() in your code, then. 8-). > >> 2) strftime must return national data (LC_TIME). > > >Explicitly call setlocale(). > > See above. Not applicable or XPG/3 would have been impossible to implement. Fix the code. > >KOI8 is a peculiar locale in that it doesn't follow the 8859-x rules > >like it should. Like EBCDIC, it needs to die in the long term. On > > And WHY IT SHOULD DO anything? It is EXISTEN CODE TABLE and LOCALES > must be adopted for it and not vice versa. I promise you that > it never dies in nearest 20-40 years, its population grows > whith each new Internet user. That's too bad. I guess you will have to properly localize in order to use software, then, instead of taking advantage of 8859-x formulation rules to get 90% soloutions. Like you'd be able to do if the standard you chose to use met those guidelines. Or you'll have to run local hacks, like the one currently in crt0.o, which is unobtrusive now, but which you wanted to make very obtrusive, when most of us were under the impression that it was a temporary hack that was going to go away. > >This whole issue is very similar to the problems that were involved in > >going to an unmapped page 0, causing NULL dereferences to SIGSEGV. In > >the short term, you lost functionality because you couldn't run some > >programs you used to be able to run. > > It isn't correct example for this case. Why not? You are arguing that your hack is OK, though it violates the rule of least astonisment by killing, among other things, xterm. Similarly, the unmapping of page 0 violates the rule of least astonishment by making programs that used to work fail. Is one standards-adherence forced failure superior to another? > >In the locale case, you lose the ability to run 8 bit clean code as if > >it had been properly internationalized, while making other code plain > >miserable to use. > > > >Without the imlied setlocale() call in crt0.o, there is an immediate > >benefit of ~1.1M of disk in static binaries (from Kaleb's numbers), and > > It is less than this value, if you want, I'll tell exactly. I think the important question is "is it non-zero?". > >the code that isn't internationalized becomes readily apparent. Just > >as the code that dereferenced NULL became readily apparent when page 0 > >was unmapped. > > *WHO* will internationalize such code? People who get pissed off when it fails. People they piss off by complaining to them. The authors, who get pissed off when people complain to them. The entire point of doing things this way was an attempt to increase the annoyance factor for American software companies who wanted to get into international markets and force them to do the right thing by getting pissed off OEMs, VARs, VADs, and users on their backs. > >Setting an "undefined" equality with 8859-1 preserves 8 bit clean > >operability in the majority of cases, and in the others, the only > >way that they could have been able to get the functionality was to > >have partially internationalized their code (you can't get at the > >altered collation sequence without some knowledge of internationalization > >implicit in the code). > > > >The net effect is that more code gets internationalized correctly, which > >is in everyone's best interests and increases the code portability instead > >of tying the users to FreeBSD. > > Well, as I already say only thing that makes me stay against > propogating was non-matched is*() stuff. From your words > I assume that you simple do nothing with it and marks > incompatibles as 'improper i18n in any case', well, > it is the way :-) Yes. Remember that most of the issues of sort order, etc., aren't fixed for anyone but the US and Great Britain anyway. It's *still* broken with an 8859-1 C locale. > BTW, > > I assume to keep my hack in the state as is, because too many > russian users already relays on it. I consider possibilites to > reduce bloat by ways that Bruce point, i.e. libc ctype cleanup > and two different startup_locale stubs for real ctype and for fake. Probably it would do well to #ifdef your hack and default it to off; then the annoyance choice is whether to fix the program or rebuild the system, with the hope being that the program gets fixed. It's possible that you could set up a distribution or alternate binaries with the hack in place. If so, they should be annoying to obtain. 8-). Answering questions that the answer is to get the other binaries or rebuild the system is the annoyance factor for people in the ASCII or 8859-1 locales need to make them fix their code. Like me. Without something like this, we Americans (and, presumably, the British) will sit on our butts and keep writing bogus code. We don't care: it doesn't matter to us if the C locale is 7 bit ASCII or 8859-1, our butt is covered, the code will work on our boxes. Makes me want to define a C locale that has nothing but trash in it. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 19:51:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA05408 for hackers-outgoing; Mon, 16 Oct 1995 19:51:01 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA05403 for ; Mon, 16 Oct 1995 19:50:57 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA26292; Mon, 16 Oct 1995 19:45:53 -0700 From: Terry Lambert Message-Id: <199510170245.TAA26292@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 19:45:53 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, kaleb@x.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 17, 95 05:27:12 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1422 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >Or to specify XPG/3 instead of XPG/4. XPG/4 marked the introduction of > >the heinously bogus runic encoding methods and thus wide character process > >encoding. If you specify XPG/3, then you will be fine. > > Well, I plan to go and fix all current ctype-aware FreeBSD sources > to call setlocale() first. I can remove my hack only after > this step will be done. So, I need to know exactly, what XPG we > plan to support. If we don't plan to support runic encoding, > we can reduce current bloat much more by removing runic. In early days > I plan to see strict 8bit locale into FreeBSD but Garrett was who > introduce runic locale. I prefer not use runic, of course. Actually, I prefer XPG/4 if we have to use the idiotic setlocale() mechanism at all. The net effect will be to break the code almost everywhere for 8bit unclean code, break code features like collation/ispunct()/etc. for 8bit clean but non-setlocale() calling code, and break things utterly for 8bit clean code in a runic locale. Get that annoyance factor right up there. 8-). I believe a full XPG implementation was placed under UCB style distribution by Sun as part of the last OpenLook/Openview ditribution (comp.sources.sun, comp.sources.x, ftp.x.org/contrib). I think it was just XPG/3, though. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 19:54:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA05554 for hackers-outgoing; Mon, 16 Oct 1995 19:54:42 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA05547 for ; Mon, 16 Oct 1995 19:54:39 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA26308; Mon, 16 Oct 1995 19:47:46 -0700 From: Terry Lambert Message-Id: <199510170247.TAA26308@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 19:47:46 -0700 (MST) Cc: roberto@keltia.freenix.fr, terry@lambert.org, dawes@rf900.physics.usyd.edu.au, hackers@freefall.freebsd.org, kaleb@x.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 17, 95 05:32:39 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 955 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >> LANG=fr_FR.ISO_8859-1 > >> LC_CTYPE=iso_8859_1 > >> > >> As soon as I switch LC_CTYPE to fr_FR.ISO_8859-1, all xterms started from > >> this terminal will dump core (well, they won't because xterm is setuid > >> root), each time. The signal is SEGV. > > >Your xterm is improperly pretending to be internationalized. It's > >pretending because there is bogus code in crt0.o that causes it to > >call setlocale() when XPG/3 and XPG/4 both say it shouldn't. > > Be shure that your propogating cause the same effect on xterm as > my hack (the same code table loaded). No it won't. The LC_TYPE causes the load to fail for the default set and there is no default set, so boom. In the case of a statically loaded (writeable strings) default, there is no setlocale() call, thus no failure, thus no core. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 19:58:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA05819 for hackers-outgoing; Mon, 16 Oct 1995 19:58:06 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA05808 for ; Mon, 16 Oct 1995 19:58:00 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id MAA20937; Tue, 17 Oct 1995 12:54:26 +1000 Date: Tue, 17 Oct 1995 12:54:26 +1000 From: Bruce Evans Message-Id: <199510170254.MAA20937@godzilla.zeta.org.au> To: ache@astral.msk.su, bde@zeta.org.au, phk@critter.tfs.com Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Cc: hackers@freefall.freebsd.org, j@uriah.heep.sax.de, kaleb@x.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >Ok, it seems your idea to have two startup_locale stubs is useful. >I think before implementing it we need to cleanup our libc (as >well as other libraries too) to _not_ use ctype calls in pure-ASCII >case and separate functions wich uses them from ones which not uses. >It can takes much time... Agreed. Bruce From owner-freebsd-hackers Mon Oct 16 20:05:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA06222 for hackers-outgoing; Mon, 16 Oct 1995 20:05:59 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA06217 for ; Mon, 16 Oct 1995 20:05:57 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA26337; Mon, 16 Oct 1995 20:00:53 -0700 From: Terry Lambert Message-Id: <199510170300.UAA26337@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 20:00:53 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.freebsd.org, kaleb@x.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 17, 95 05:29:15 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 507 Sender: owner-hackers@FreeBSD.org Precedence: bulk > In message <199510170120.SAA26017@phaeton.artisoft.com> Terry Lambert > writes: > > >Space isn't 0x20 in 8859-5? Tab, LF, CR aren't the same? > > Space is 0xA0 too. You have two space bars? No, I know that typical usage calls this a "hard space", per the word processing/document formatting usage in WPS. You have scored a point, but not a convincing one. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 20:12:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA06517 for hackers-outgoing; Mon, 16 Oct 1995 20:12:53 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id UAA06510 for ; Mon, 16 Oct 1995 20:12:48 -0700 Received: by sovcom.kiae.su id AA13474 (5.65.kiae-1 ); Tue, 17 Oct 1995 06:11:45 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 06:11:45 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id GAA01294; Tue, 17 Oct 1995 06:08:24 +0300 To: Terry Lambert Cc: hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, kaleb@x.org References: <199510170245.TAA26292@phaeton.artisoft.com> In-Reply-To: <199510170245.TAA26292@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 19:45:53 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 06:08:23 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 16 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 710 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510170245.TAA26292@phaeton.artisoft.com> Terry Lambert writes: >I believe a full XPG implementation was placed under UCB style distribution >by Sun as part of the last OpenLook/Openview ditribution (comp.sources.sun, >comp.sources.x, ftp.x.org/contrib). I think it was just XPG/3, though. We can easily make XPG/3 from our XPG/4, I already do 90% of this work when make startup_locale() hack. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 20:13:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA06546 for hackers-outgoing; Mon, 16 Oct 1995 20:13:14 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id UAA06535 for ; Mon, 16 Oct 1995 20:13:09 -0700 Received: by sovcom.kiae.su id AA13471 (5.65.kiae-1 ); Tue, 17 Oct 1995 06:11:44 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 06:11:44 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id GAA01285; Tue, 17 Oct 1995 06:05:01 +0300 To: Terry Lambert Cc: hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, kaleb@x.org References: <199510170239.TAA26264@phaeton.artisoft.com> In-Reply-To: <199510170239.TAA26264@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 19:39:54 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 06:05:01 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 39 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1817 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510170239.TAA26264@phaeton.artisoft.com> Terry Lambert writes: >> >I can *potentially* see ispunct() (though I can't think of any >BS. Read XPG/3, which doesn't know about multibyte characters, yet >defines setlocale(). >It's true that calling an XPG/4 setlocale() in an 8-bit clean, multibyte >unaware program in a runic encoded/multibyte locale will fail. The >soloution is to fix the program. Right now we can't use setlocale() in any code because have XPG/4 in libc. Fixing any program for XPG/4 is very non-trivial task and you says that it not used in any case. All ports software which calls setlocale() assumes XPG/3, so it is already broken for runes. It seems that we needs to change 4 -> 3 and remove bloat taken by runic encoding. >> >KOI8 is a peculiar locale in that it doesn't follow the 8859-x rules >> >like it should. Like EBCDIC, it needs to die in the long term. On >> >> And WHY IT SHOULD DO anything? It is EXISTEN CODE TABLE and LOCALES >> must be adopted for it and not vice versa. I promise you that >> it never dies in nearest 20-40 years, its population grows >> whith each new Internet user. >That's too bad. I guess you will have to properly localize in order >to use software, then, instead of taking advantage of 8859-x formulation >rules to get 90% soloutions. Like you'd be able to do if the standard >you chose to use met those guidelines. I can't see why KOI8-R charset needs to follow 8859-x rules when setlocale() called, it simple becomes loaded as is. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 20:15:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA06626 for hackers-outgoing; Mon, 16 Oct 1995 20:15:01 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id UAA06615 for ; Mon, 16 Oct 1995 20:14:57 -0700 Received: by sovcom.kiae.su id AA13476 (5.65.kiae-1 ); Tue, 17 Oct 1995 06:11:46 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 06:11:46 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id GAA01303; Tue, 17 Oct 1995 06:10:30 +0300 To: Terry Lambert Cc: dawes@rf900.physics.usyd.edu.au, hackers@freefall.freebsd.org, kaleb@x.org, roberto@keltia.freenix.fr References: <199510170247.TAA26308@phaeton.artisoft.com> In-Reply-To: <199510170247.TAA26308@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 19:47:46 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 06:10:30 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 33 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1417 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510170247.TAA26308@phaeton.artisoft.com> Terry Lambert writes: >> >> LANG=fr_FR.ISO_8859-1 >> >> LC_CTYPE=iso_8859_1 >> >> >> >> As soon as I switch LC_CTYPE to fr_FR.ISO_8859-1, all xterms started from >> >> this terminal will dump core (well, they won't because xterm is setuid >> >> root), each time. The signal is SEGV. >> >> >Your xterm is improperly pretending to be internationalized. It's >> >pretending because there is bogus code in crt0.o that causes it to >> >call setlocale() when XPG/3 and XPG/4 both say it shouldn't. >> >> Be shure that your propogating cause the same effect on xterm as >> my hack (the same code table loaded). >No it won't. The LC_TYPE causes the load to fail for the default >set and there is no default set, so boom. >In the case of a statically loaded (writeable strings) default, there >is no setlocale() call, thus no failure, thus no core. Not this case. This case is equal simple LANG set or not set, LC_CTYPE bogusly involved here. I dump xterm core only by LANG and don't need LC_CTYPE for it. Having bogus LC_CTYPE simple mask LANG presence. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 16 20:17:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA06741 for hackers-outgoing; Mon, 16 Oct 1995 20:17:30 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA06715 ; Mon, 16 Oct 1995 20:17:22 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id NAA21632; Tue, 17 Oct 1995 13:12:33 +1000 Date: Tue, 17 Oct 1995 13:12:33 +1000 From: Bruce Evans Message-Id: <199510170312.NAA21632@godzilla.zeta.org.au> To: matt@lkg.dec.com, terry@lambert.org Subject: Re: suggested changes to mbuf routines Cc: hackers@freefall.freebsd.org, julian@freefall.freebsd.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >> #if __STDC__ >> void (*ext_free)(caddr_t, u_long, caddr_t); >> #else >> void (*ext_free)(); /* free routine if not the usual */ >> #endif >... >> void (*ext_free)(caddr_t, u_long, caddr_t); >Should be: >> void (*ext_free) __P((caddr_t, u_long, caddr_t)); The __STDC__ test already does that, but I prefer __P(()) because it takes 1 line instead of 5 and the unportable conditional is easier to change. The caddr_t's are bogus because free() takes a `void *' arg even in the kernel. The u_long is fairly bogus, but malloc() takes a u_long arg instead of a size_t arg too. We have been removing bogus casts to (caddr_t) for `void *' function args. Perhaps that has gone a bit far. There is no problem in ANSI C, but in K&R C the following change is incorrect: void func __P((void *)); int *foo; from: func((caddr_t)foo); /* works because addr_t has same * representation as void *, but bogus */ to: func(foo); /* works in ANSI C; fails in K&R C if * void * has a different representation * to int * */ "right": func((void *)foo); /* "always" works; actually it only works * if the K&R compiler is not krufty enough * to be missing void *, and not braindamaged * enough to use different representations * for void * and caddr_t */ Bruce From owner-freebsd-hackers Mon Oct 16 20:26:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA07027 for hackers-outgoing; Mon, 16 Oct 1995 20:26:44 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA07019 for ; Mon, 16 Oct 1995 20:26:39 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA26486; Mon, 16 Oct 1995 20:21:36 -0700 From: Terry Lambert Message-Id: <199510170321.UAA26486@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 20:21:36 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, kaleb@x.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 17, 95 06:05:01 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 841 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >That's too bad. I guess you will have to properly localize in order > >to use software, then, instead of taking advantage of 8859-x formulation > >rules to get 90% soloutions. Like you'd be able to do if the standard > >you chose to use met those guidelines. > > I can't see why KOI8-R charset needs to follow 8859-x rules > when setlocale() called, it simple becomes loaded as is. If it did already, then this discussion would be over, since the change wouldn't be upgrading Western Europe's C locale and not upgrading yours. It seems that that is the real problem: equal access, not really that you honestly believe that the hack should remain and the code should not have to be fixed. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 20:31:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA07164 for hackers-outgoing; Mon, 16 Oct 1995 20:31:23 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA07159 ; Mon, 16 Oct 1995 20:31:19 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA26514; Mon, 16 Oct 1995 20:24:54 -0700 From: Terry Lambert Message-Id: <199510170324.UAA26514@phaeton.artisoft.com> Subject: Re: suggested changes to mbuf routines To: bde@zeta.org.au (Bruce Evans) Date: Mon, 16 Oct 1995 20:24:54 -0700 (MST) Cc: matt@lkg.dec.com, terry@lambert.org, hackers@freefall.freebsd.org, julian@freefall.freebsd.org In-Reply-To: <199510170312.NAA21632@godzilla.zeta.org.au> from "Bruce Evans" at Oct 17, 95 01:12:33 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1174 Sender: owner-hackers@FreeBSD.org Precedence: bulk > The caddr_t's are bogus because free() takes a `void *' arg even in the > kernel. The u_long is fairly bogus, but malloc() takes a u_long arg > instead of a size_t arg too. > > We have been removing bogus casts to (caddr_t) for `void *' function args. > Perhaps that has gone a bit far. There is no problem in ANSI C, but in > K&R C the following change is incorrect: > > void func __P((void *)); > int *foo; > from: > func((caddr_t)foo); /* works because addr_t has same > * representation as void *, but bogus */ > to: > func(foo); /* works in ANSI C; fails in K&R C if > * void * has a different representation > * to int * */ > "right": > func((void *)foo); /* "always" works; actually it only works > * if the K&R compiler is not krufty enough > * to be missing void *, and not braindamaged > * enough to use different representations > * for void * and caddr_t */ The more you code, the more there is that needs coded. 8-(. Man... we need to get *done* on some of these things. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 16 20:42:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA07468 for hackers-outgoing; Mon, 16 Oct 1995 20:42:44 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA07458 ; Mon, 16 Oct 1995 20:42:40 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id UAA17128; Mon, 16 Oct 1995 20:42:27 -0700 Received: from freefall.freebsd.org (freefall [192.216.222.4]) by ref.tfs.com (8.6.11/8.6.9) with ESMTP id SAA16795 for ; Mon, 16 Oct 1995 18:22:50 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA02520 for ; Mon, 16 Oct 1995 18:23:01 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id SAA16783; Mon, 16 Oct 1995 18:21:09 -0700 From: Julian Elischer Message-Id: <199510170121.SAA16783@ref.tfs.com> Subject: Re: suggested changes to mbuf routines To: terry@lambert.org (Terry Lambert) Date: Mon, 16 Oct 1995 18:21:08 -0700 (PDT) Cc: matt@lkg.dec.com, julian@freefall.freebsd.org, hackers@freefall.freebsd.orgrgrimes@freebsd.org In-Reply-To: <199510162001.NAA25213@phaeton.artisoft.com> from "Terry Lambert" at Oct 16, 95 01:01:07 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1498 Sender: owner-hackers@freebsd.org Precedence: bulk > In <199510141119.EAA05158@freefall.freebsd.org> , you wrote: > > I find the method of doing the references as done in Digital UNIX > (aka DEC OSF/1) quite clean. Basically the m_ext struct gets an > queue entry added. When the extended mbuf is first allocated, the > link queue entry merely points to itself (an empty queue). As more > references are made, their queues get linked together. As references > are removed, their queues get unlinked. > > To see if there is a non-zero reference count, imply see if the queue > entry points to itself. ah I was wondering what that was... I was looking at that in OSF1/i386 and scratching my head about it.. I guess that means that whatever is externally allocated need not have it's own reference counts.. (unless they are also used elsewhere than for mbufs) not sure which I prefer.. rod, is this given in the device driver's book? > > > /* description of external storage mapped into mbuf, valid if M_EXT set */ > struct m_ext { > caddr_t ext_buf; /* start of buffer */ > void (*ext_free)(caddr_t, u_long, caddr_t); > u_int ext_size; /* size of buffer, for ext_free */ > caddr_t ext_arg; /* additional ext_free argument */ > struct ext_refq { /* reference list */ > struct ext_refq *forw, *back; > } ext_ref; > }; > > #define MCLREFERENCED(m) \ > ((m)->m_ext.ext_ref.forw != &((m)->m_ext.ext_ref)) From owner-freebsd-hackers Mon Oct 16 20:48:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA07736 for hackers-outgoing; Mon, 16 Oct 1995 20:48:51 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA07728 for ; Mon, 16 Oct 1995 20:48:45 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id NAA08422; Tue, 17 Oct 1995 13:50:19 +0930 From: Michael Smith Message-Id: <199510170420.NAA08422@genesis.atrad.adelaide.edu.au> Subject: Re: IO errors in multi-IO card by kernel To: moonhunt@easy.re.kr (HyunSeog Ryu) Date: Tue, 17 Oct 1995 13:50:18 +0930 (CST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199510160706.QAA03935@ns.easy.re.kr> from "HyunSeog Ryu" at Oct 16, 95 04:06:07 pm Content-Type: text Content-Length: 1235 Sender: owner-hackers@freebsd.org Precedence: bulk HyunSeog Ryu stands accused of saying: > > I use P-75 machine with FreeBSD 2.0.5-950622-SNAP. > I was installed multi-serial 4-port card to connect modem for BBS. > It was runned correctly. > But today it's kernel report some error message to console, > and serial is not work. "is not work" - at all? partly? is it giving off smoke? More details, please. > message is below. > > Oct 16 15:53:05 bbs /kernel: sio4: 1 more silo overflow(total 1) > > What's mean??? I was rebuild kernel by config & make. > As to AST 4 port's method, it was runnung correctly... Ah, you screwed up your kernel config. Please send your old and new kernel config files also. > Please let me know this message's meaning... ;< The message means that the system was too busy to service a serial port interrupt, and one or more bytes were lost. > From Hyunseog Ryu -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Mon Oct 16 20:49:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA07761 for hackers-outgoing; Mon, 16 Oct 1995 20:49:09 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA07751 for ; Mon, 16 Oct 1995 20:49:04 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id NAA08431; Tue, 17 Oct 1995 13:51:39 +0930 From: Michael Smith Message-Id: <199510170421.NAA08431@genesis.atrad.adelaide.edu.au> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 17 Oct 1995 13:51:39 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, freebsd-hackers@freebsd.org In-Reply-To: <199510160737.IAA24201@uriah.heep.sax.de> from "J Wunsch" at Oct 16, 95 08:37:42 am Content-Type: text Content-Length: 951 Sender: owner-hackers@freebsd.org Precedence: bulk J Wunsch stands accused of saying: > The smtp error message is not intended for trained IBM personell that > is good enough in Japanese to even understand the Japanese error > messages :), it's intended for the _sender_ of the message. So unless > IBM is in the belief that all the world is AIX trained personell > (maybe they're really believing this, who knows? :-), this attitude is > not very useful. Ah, we're at odds. Certainly, a mail bounce message should be in english, or possibly esperanto 8) I was referring to _local_ error messages 8) > cheers, J"org -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Mon Oct 16 21:03:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA08352 for hackers-outgoing; Mon, 16 Oct 1995 21:03:17 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA08344 for ; Mon, 16 Oct 1995 21:03:09 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id OAA23474; Tue, 17 Oct 1995 14:00:00 +1000 Date: Tue, 17 Oct 1995 14:00:00 +1000 From: Bruce Evans Message-Id: <199510170400.OAA23474@godzilla.zeta.org.au> To: bde@zeta.org.au, matt@lkg.dec.com Subject: Re: IPX now available Cc: hackers@freebsd.org, se@zpr.uni-koeln.de Sender: owner-hackers@freebsd.org Precedence: bulk >> Device drivers will >> need to be able to sleep in their probe and attach routines for other >> reasons. When tsleep() at probe and attach time is implemented, >> complicated time-dependent orderings (aka races :-) will be easy to >> implemented - just sleep until the modules that you depend on are >> loaded. >It depends on when drivers will be probed but if we assume it's before >the process initialization, then this begs for kernel threads. While >highly desirable, I think kernel threads would be overkill if added >just for this. Instead, use of timeout() and proper sync points would >achieve the same capability at far less implementation cost. timeout() is no use if there is nothing to give up control to. I think some sort of threading is required, and I want something that has the same interface for drivers that are probed early and ones that are probed after the system is running normally. tsleep() is good enough for the latter case and its interface is probably be good enough for early use. tsleep() itself could do something like `if (cold) next_mini_thread(); else normal_stuff();'. Br4uce From owner-freebsd-hackers Mon Oct 16 22:16:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA09711 for hackers-outgoing; Mon, 16 Oct 1995 22:16:07 -0700 Received: from chrome.jdl.com (chrome.onramp.net [199.1.166.202]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA09705 for ; Mon, 16 Oct 1995 22:16:04 -0700 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.jdl.com (8.6.11/8.6.9) with SMTP id XAA04810; Mon, 16 Oct 1995 23:01:43 -0500 Message-Id: <199510170401.XAA04810@chrome.jdl.com> X-Authentication-Warning: chrome.jdl.com: Host localhost.jdl.com didn't use HELO protocol To: Bruce Evans cc: mark@grondar.za, hackers@FreeBSD.org Subject: Re: Creating a /dev/random In-reply-to: Your message of "Tue, 17 Oct 1995 11:23:55 +1000." <199510170123.LAA17511@godzilla.zeta.org.au> Reply-To: jdl@chromatic.com Clarity-Index: null Threat-Level: none Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Date: Mon, 16 Oct 1995 23:01:42 -0500 From: Jon Loeliger Sender: owner-hackers@FreeBSD.org Precedence: bulk Apparently, Bruce Evans scribbled: > >>I don't understand something here - what happens if the one process is > >>reading both /dev/zero and /dev/random? will the two not then try to > >>share buf/zbuf and screw up? > > >See above > > Oops, I misread `one process'. Well, one process can't be in the kernel > twice. ...until SMP is implemented and then the whole locking issue comes into play, right? jdl From owner-freebsd-hackers Mon Oct 16 22:21:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA09849 for hackers-outgoing; Mon, 16 Oct 1995 22:21:22 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA09833 for ; Mon, 16 Oct 1995 22:21:18 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id GAA25342 for ; Tue, 17 Oct 1995 06:21:13 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id GAA26646 for freebsd-hackers@freebsd.org; Tue, 17 Oct 1995 06:21:13 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id XAA27324 for freebsd-hackers@freebsd.org; Mon, 16 Oct 1995 23:48:32 +0100 From: J Wunsch Message-Id: <199510162248.XAA27324@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Mon, 16 Oct 1995 23:48:31 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510162043.NAA25342@phaeton.artisoft.com> from "Terry Lambert" at Oct 16, 95 01:43:00 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 716 Sender: owner-hackers@freebsd.org Precedence: bulk As Terry Lambert wrote: > > > What you mean by majority? Russian users amount is comparable > > with all european users, why not extend default table to KOI8-R > > instead? > > Because post ANSI 3.64 terminal control codes reserve 0x80..0x9f and > KOI8-R does not respect this international standard? Terry, before giving public statements, please look at the character set. It's included in the latest public fix from XConsortium and in XFree86 3.1.2, so you shouldn't have a hard time to find something about it. Use "xfd" to display it locally... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Oct 16 22:21:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA09864 for hackers-outgoing; Mon, 16 Oct 1995 22:21:27 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA09843 for ; Mon, 16 Oct 1995 22:21:21 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id GAA25338 for ; Tue, 17 Oct 1995 06:21:12 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id GAA26645 for freebsd-hackers@freebsd.org; Tue, 17 Oct 1995 06:21:11 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id XAA27289 for freebsd-hackers@freebsd.org; Mon, 16 Oct 1995 23:45:16 +0100 From: J Wunsch Message-Id: <199510162245.XAA27289@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Mon, 16 Oct 1995 23:45:15 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510162034.NAA25305@phaeton.artisoft.com> from "Terry Lambert" at Oct 16, 95 01:34:10 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1667 Sender: owner-hackers@freebsd.org Precedence: bulk As Terry Lambert wrote: > > The problem with KOI-8 is that KOI-8 is a defacto standard, and is not > accepted by international standards bodies. Mostly because the most > popular BBS software in the area picked it up instead of 8859-9. The X Consortium finally agreed to accept koi8-r as a valid character set/encoding. :-) Well, if we would rely on things like ISO, we wouldn't use IP etc. and suffer from OSI/X.400 instead... > The problem is not in the blank areas of the locale. > > In point of fact, the ANSI standards for terminal control sequences > after ANSI 3.64 leave the codes in columns 0x80 and 0x90 to be used > to represent 8 bit command sequence introducers, which are the same > as an escape character followed by a character in columns 0x20 or 0x30. > Because of this, KOI-8 as a character set is not compatible with post > 3.64 ANSI terminal control sequence standardization. Do you know KOI8-R? It doesn't even touch those areas. This is NOT IBM's code page crime. KOI8-R does basically use the same printable characters like ISO-8859-*. The most notable difference to the ISO-8859-* fonts is that KOI has the upper/lower case reversed for some obscure reason. > Really, they should be using the 8859 character set instead of KOI-8, > but there is understood to be a large historical investment in the > non-standard KOI-8 representation (unfortunately). You're sounding like the OSI protagonists when they started the German educational network project (WiN) here. :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Oct 16 22:56:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA10309 for hackers-outgoing; Mon, 16 Oct 1995 22:56:01 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA10303 for ; Mon, 16 Oct 1995 22:55:51 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id HAA24602; Tue, 17 Oct 1995 07:55:34 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id HAA29644; Tue, 17 Oct 1995 07:55:33 +0200 Message-Id: <199510170555.HAA29644@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: Bruce Evans cc: hackers@FreeBSD.org Subject: Re: Creating a /dev/random Date: Tue, 17 Oct 1995 07:55:33 +0200 From: Mark Murray Sender: owner-hackers@FreeBSD.org Precedence: bulk > >> To avoid this, use the existing buffer `zbuf', which is freed correctly. > >> There is no need for another variable - local variables are per process. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> Perhaps `zbuf' should be renamed `buf'. > > >I don't understand something here - what happens if the one process is > >reading both /dev/zero and /dev/random? will the two not then try to > >share buf/zbuf and screw up? > > See above Either you are missing something here or I am :-) If ONE process is reading BOTH /dev/random and /dev/zero (making buf common?) is there a problem? > >> is inelegant anyway. Perhaps there should be a zeroout() function to > >> optimize this important (;-) device. > > >...or only c bytes should be zero'ed out? > > Good idea. Will do! -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-hackers Mon Oct 16 22:59:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA10365 for hackers-outgoing; Mon, 16 Oct 1995 22:59:20 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA10354 for ; Mon, 16 Oct 1995 22:59:07 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id HAA24606; Tue, 17 Oct 1995 07:58:27 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id HAA29664; Tue, 17 Oct 1995 07:58:26 +0200 Message-Id: <199510170558.HAA29664@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: Bruce Evans cc: hackers@FreeBSD.org Subject: Re: Creating a /dev/random Date: Tue, 17 Oct 1995 07:58:25 +0200 From: Mark Murray Sender: owner-hackers@FreeBSD.org Precedence: bulk > >>I don't understand something here - what happens if the one process is > >>reading both /dev/zero and /dev/random? will the two not then try to > >>share buf/zbuf and screw up? > > >See above > > Oops, I misread `one process'. Well, one process can't be in the kernel > twice. I replied to this 10 seconds ago - please ignore that reply. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-hackers Mon Oct 16 23:37:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA11252 for hackers-outgoing; Mon, 16 Oct 1995 23:37:35 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA11247 for ; Mon, 16 Oct 1995 23:37:23 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA29789; Tue, 17 Oct 1995 16:33:34 +1000 Date: Tue, 17 Oct 1995 16:33:34 +1000 From: Bruce Evans Message-Id: <199510170633.QAA29789@godzilla.zeta.org.au> To: bde@zeta.org.au, jdl@chrome.onramp.net Subject: Re: Creating a /dev/random Cc: hackers@FreeBSD.org, mark@grondar.za Sender: owner-hackers@FreeBSD.org Precedence: bulk >> Oops, I misread `one process'. Well, one process can't be in the kernel >> twice. >...until SMP is implemented and then the whole locking issue >comes into play, right? No. Until async i/o is implemented, perhaps. Bruce From owner-freebsd-hackers Tue Oct 17 00:12:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA12129 for hackers-outgoing; Tue, 17 Oct 1995 00:12:13 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA12122 for ; Tue, 17 Oct 1995 00:11:59 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id AAA17450 for hackers@freeBSD.org; Tue, 17 Oct 1995 00:11:44 -0700 From: Julian Elischer Message-Id: <199510170711.AAA17450@ref.tfs.com> Subject: netisr code.. To: hackers@freeBSD.org Date: Tue, 17 Oct 1995 00:11:44 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 634 Sender: owner-hackers@freeBSD.org Precedence: bulk Why is it done like this? swi_net: MCOUNT bsfl _netisr,%eax je swi_net_done swi_net_more: btrl %eax,_netisr jnc swi_net_next <------should never happen call *_netisrs(,%eax,4) swi_net_next: bsfl _netisr,%eax jne swi_net_more swi_net_done: ret casual inspection suggests that the following would be as good.. swi_net: MCOUNT swi_net_next: bsfl _netisr,%eax je swi_net_done btrl %eax,_netisr call *_netisrs(,%eax,4) jmp swi_net_next swi_net_done: ret From owner-freebsd-hackers Tue Oct 17 00:23:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA12303 for hackers-outgoing; Tue, 17 Oct 1995 00:23:49 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA12298 for ; Tue, 17 Oct 1995 00:23:35 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA31630; Tue, 17 Oct 1995 17:21:33 +1000 Date: Tue, 17 Oct 1995 17:21:33 +1000 From: Bruce Evans Message-Id: <199510170721.RAA31630@godzilla.zeta.org.au> To: ache@astral.msk.su, kaleb@x.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Cc: hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >>Now all that goals are reached by 'setenv ENABLE_STARTUP_LOCALE' >>and without any program modifications. >EXCEPT THAT VIOLATES ANSI/POSIX/ISO C, which stipulates that on the >entry to main() the program must be in the C locale. People who use >this hack on correctly written programs find that it breaks their >programs in not very subtle ways, as you've already found with the >i18n-aware xterm that XFree86 distributes. You don't have to use ENABLE_STARTUP_LOCALE if you want full conformance. Let me give some examples of ctype and locale brokenness in X, not to pick on you or X, but to show how hard it is to do things right. I only have the XF311 sources to look at; perhaps the originals are better. xterm/main.c: Begins with setlocale(LC_ALL, NULL). This reads the current locale and throws away the value (except possibly on K&R systems with NULL defined as 0, when the uncast NULL may cause a core dump). The current locale is guaranteed to be the C locale on ANSI conformant systems so there is no point in reading it. xprop/xprop.c: `char *string; ... isalpha(string[0])' should dump core if string[0] is negative and not EOF. Another of ache's hacks makes it work right. The hack breaks ctype's handling of EOF, however. xrdb/xrdb.c: `char c; ... isalpha(c)' should dump core as above. These are trivial bugs. If programs can't call isalpha() with correct args, I have no confidence in them handling locale complications in full generailty. >>It is especially essential when >>program isn't FreeBSD native but comes from 3rd party, i.e. >>ports area. Moreover, they can be reached on any remote system >>too, includes freefall f.e. >Then perhaps the process of putting something into ports should include >minimally localizing the program to set the locale to whatever the >user has set in his or her LC_ALL, LC_CTYPE, or LANG environment variable. There aren't enough resources or interest. The core sources should be localized before ports, but haven't been. The following programs in /usr/src/*bin/*.c call setlocale(): csh, ee. That's all. >>Maybe this functionality isn't kosher but you even can't imagine how >>it is useful. >Let me get this straight. You're willing to compromise ANSI/POSIX/ISO >compliance because the functionality is useful. I'm not even asking to >compromise compliance and still get some useful behavior, and your >response is to make up completely bogus arguments like ANSI requires >the C locale to be strictly ASCII, no more, no less. I wonder if NetBSD >is this broken? I'm starting to think it might be time to switch camps. I think tradition is what requires the C locale to be strictly ASCII. Hmm. _startup_setlocale() could change things that aren't specified by ANSI - it could change the behaviour of isprint() and isspace() according to $LANG, but it can't change the behaviour of isupper() etc. This would fix ls. Bruce From owner-freebsd-hackers Tue Oct 17 00:55:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA12841 for hackers-outgoing; Tue, 17 Oct 1995 00:55:30 -0700 Received: from netcom17.netcom.com (root@netcom17.netcom.com [192.100.81.130]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA12821 ; Tue, 17 Oct 1995 00:55:19 -0700 Received: from localhost by netcom17.netcom.com (8.6.12/Netcom) id AAA00821; Tue, 17 Oct 1995 00:26:43 -0700 Message-Id: <199510170726.AAA00821@netcom17.netcom.com> To: Terry Lambert cc: hackers@freefall.freebsd.org, current@freefall.freebsd.org Subject: Re: getdtablesize() broken? In-reply-to: Your message of "Mon, 16 Oct 95 11:31:02 PDT." <199510161831.LAA25019@phaeton.artisoft.com> Date: Tue, 17 Oct 95 00:26:42 -0700 From: Bakul Shah Sender: owner-hackers@FreeBSD.org Precedence: bulk > Using FD_SETSIZE or using RLIMIT_NOFILE, or getting the current open > descriptor limit from the kernel (when the application has an explicit > bitvector element limitation set at compile time, not because of a > check for FD_SETSIZE by because declaration of a bit vector uses the > FD_SETSIZE to declare the vector length) is equally stupid and equally > succeptible to screwups. > The "correct" way is to get rid of the interfaces which are succeptible > to bad programming style. The user *SHOULD* be using the highest open > FD in the set of FD's being selected upon, *NOT* some arbitrary constant. My mistake. I didn't explicitly state that I was bitching about an *in-kernel* limitation. Granted that an application should use what you suggest but the problem is that a {Free|Net}BSD _kernel_ restricts nfds that can be passed to select() to FD_SETSIZE. I can open, say, 1000 sockets, there is no way I can select on an fd >= FD_SETSIZE. Unshar the attached little program and try this test. % cc x.c % limit openefiles 500 # you may need to do `limit descriptors 500' % a.out 500 255 except select(). This happens because of this line in /sys/kern/sys_generic.c:select() if (uap->nd > FD_SETSIZE) It should be replaced with if (uap->nd > p->fd->fd_nfiles) It is this hardwired use of FD_SETSIZE *in* the kernel I am bitching about. There *are* scalability problems with select() and we can use a more scalable interface but regardless, select() needs to work with any valid file descriptor. --bakul #!/bin/sh # This is a shell archive (produced by shar 3.49) # To extract the files from this archive, save it to a file, remove # everything above the "!/bin/sh" line above, and type "sh file_name". # # made 10/17/1995 07:18 UTC by bakul@netcom17 # Source directory /u7/bakul # # existing files will NOT be overwritten unless -c is specified # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 502 -rw-r--r-- x.c # # ============= x.c ============== if test -f 'x.c' -a X"$1" != X"-c"; then echo 'x - skipping x.c (File already exists)' else echo 'x - extracting x.c (Text)' sed 's/^X//' << 'SHAR_EOF' > 'x.c' && #include #include #include X int main(int argc, char**argv) { X int n = argc > 1 ? atoi(argv[1]) : 257; X int * bits = calloc((n+31)/32, sizeof(int)); X int i; X X for (i = 3; i < n; i++) { X int fd = dup(0); X if (fd < 0) { X fprintf(stderr, "Can only get %d descriptors\n", i); X exit(1); X } X bits[fd/32] |= 1<<(fd%32); X if (select(fd+1, bits, 0, 0, 0) < 0) { X fprintf(stderr, "select error %s when fd = %d\n", X strerror(errno), fd); X exit(1); X } X } X exit(0); } SHAR_EOF chmod 0644 x.c || echo 'restore of x.c failed' Wc_c="`wc -c < 'x.c'`" test 502 -eq "$Wc_c" || echo 'x.c: original size 502, current size' "$Wc_c" fi exit 0 From owner-freebsd-hackers Tue Oct 17 00:57:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA12922 for hackers-outgoing; Tue, 17 Oct 1995 00:57:59 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA12917 for ; Tue, 17 Oct 1995 00:57:41 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA00245; Tue, 17 Oct 1995 17:55:47 +1000 Date: Tue, 17 Oct 1995 17:55:47 +1000 From: Bruce Evans Message-Id: <199510170755.RAA00245@godzilla.zeta.org.au> To: hackers@freeBSD.org, julian@ref.tfs.com Subject: Re: netisr code.. Sender: owner-hackers@freeBSD.org Precedence: bulk > Why is it done like this? >swi_net: > MCOUNT > bsfl _netisr,%eax > je swi_net_done >swi_net_more: > btrl %eax,_netisr > jnc swi_net_next <------should never happen > call *_netisrs(,%eax,4) >swi_net_next: > bsfl _netisr,%eax > jne swi_net_more >swi_net_done: > ret I think you're right - netisrs (including this code) are masked here, and nothing except the above btrl clears bits in _netisr. The jnc may be left over from when netisrs weren't masked here. It's cheap insurance - much faster than the btrl. >casual inspection suggests that the following would be as good.. >swi_net: > MCOUNT >swi_net_next: > bsfl _netisr,%eax > je swi_net_done > btrl %eax,_netisr > call *_netisrs(,%eax,4) > jmp swi_net_next >swi_net_done: > ret That is slower at the end. However, micro-optimizations here are probably not important. Everything except the atomic btrl could be written in C and you probably wouldn't notice the difference. Bruce From owner-freebsd-hackers Tue Oct 17 01:13:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA13610 for hackers-outgoing; Tue, 17 Oct 1995 01:13:50 -0700 Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA13586 for ; Tue, 17 Oct 1995 01:13:24 -0700 Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id SAA07948; Tue, 17 Oct 1995 18:09:27 +1000 From: David Dawes Message-Id: <199510170809.SAA07948@rf900.physics.usyd.edu.au> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 17 Oct 1995 18:09:27 +1000 (EST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199510162245.XAA27289@uriah.heep.sax.de> from "J Wunsch" at Oct 16, 95 11:45:15 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 894 Sender: owner-hackers@freebsd.org Precedence: bulk >> The problem with KOI-8 is that KOI-8 is a defacto standard, and is not >> accepted by international standards bodies. Mostly because the most >> popular BBS software in the area picked it up instead of 8859-9. > >The X Consortium finally agreed to accept koi8-r as a valid character >set/encoding. > >:-) What the X Consortium did was to accept The XFree86 Project's request to register the charset/encoding KOI8-R. I don't think it implies any more than that. There are a lot of unusual or vendor-specific chareset/encodings registered with them -- take a look in the xc/registry file. If they ship Cyrillic fonts with their next release, they've indicated (to me at least) that their preference is to use the ISO8859-5 encoding. What XFree86 would like to do in the next release, if possible, is allow the Cyrillic fonts to be built with either KOI8-R or ISO8859-5 encodings. David From owner-freebsd-hackers Tue Oct 17 01:21:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA14032 for hackers-outgoing; Tue, 17 Oct 1995 01:21:07 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA14022 for ; Tue, 17 Oct 1995 01:20:56 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id BAA01355; Tue, 17 Oct 1995 01:19:38 -0700 Message-Id: <199510170819.BAA01355@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: "Andrew V. Stesin" cc: hackers@freebsd.org Subject: Re: From BSDi mailing list on gcc-2.6.3 bugs: (fwd) A brief note about cc and gcc In-reply-to: Your message of "Mon, 16 Oct 1995 16:29:01 +0200." <199510161429.QAA26398@office.elvisti.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Oct 1995 01:19:37 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk > In 2.0, `cc' gets you gcc 1.42 and `gcc' or `gcc2' gets you 2.6.3. > Neither one of them is quite the same as the distribution version; > in particular, I have installed at least a half dozen bug fixes in > the 2.6.3 that we ship (including one that threw in a new bug, so Has anyone managed to get gcc 1.42 to work with FreeBSD 2.x? I can really use some fast compilation for development/testing. Tnks, Amancio From owner-freebsd-hackers Tue Oct 17 01:25:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA14184 for hackers-outgoing; Tue, 17 Oct 1995 01:25:17 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA14174 for ; Tue, 17 Oct 1995 01:25:02 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA29285 for ; Tue, 17 Oct 1995 09:24:23 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA27531 for freebsd-hackers@freebsd.org; Tue, 17 Oct 1995 09:24:23 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA29982 for freebsd-hackers@freebsd.org; Tue, 17 Oct 1995 08:51:25 +0100 From: J Wunsch Message-Id: <199510170751.IAA29982@uriah.heep.sax.de> Subject: Re: smtp error message i18n To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Tue, 17 Oct 1995 08:51:25 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510170421.NAA08431@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 17, 95 01:51:39 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 460 Sender: owner-hackers@freebsd.org Precedence: bulk As Michael Smith wrote: > > Ah, we're at odds. Certainly, a mail bounce message should be in english, > or possibly esperanto 8) I was referring to _local_ error messages 8) As i said: send a mail to foo@informatik.htw-dresden.de. Watch the fun, send your complaint somewhere to ibm.com. :) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Tue Oct 17 01:25:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA14236 for hackers-outgoing; Tue, 17 Oct 1995 01:25:45 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA14219 for ; Tue, 17 Oct 1995 01:25:31 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA29346 for ; Tue, 17 Oct 1995 09:25:26 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA27538 for freebsd-hackers@freebsd.org; Tue, 17 Oct 1995 09:25:26 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA29408 for freebsd-hackers@freebsd.org; Tue, 17 Oct 1995 08:11:32 +0100 From: J Wunsch Message-Id: <199510170711.IAA29408@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Tue, 17 Oct 1995 08:11:31 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510162209.PAA25573@phaeton.artisoft.com> from "Terry Lambert" at Oct 16, 95 03:09:02 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 736 Sender: owner-hackers@freebsd.org Precedence: bulk As Terry Lambert wrote: > > > It seems that every new person appears immediately starts to says > > the same ... > I've only been working on user interface internationalization for more > than 10 years, and OS internationalization for 6 years. Stop misunderstanding, please. Terry, keep in mind that English ain't Andrey's native language. His "new person" was very apparently related to "new in this discussion right now". Moshno vy govoritye po-russkij? Ya dumayu che Andrey govorit eto yazyk luchshe. :-) (Sorry, my keyboard is not yet ready for KOI8-R input. :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Tue Oct 17 01:35:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAB14606 for hackers-outgoing; Tue, 17 Oct 1995 01:35:46 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id BAA14597 ; Tue, 17 Oct 1995 01:35:33 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t57Uh-0003wFC; Tue, 17 Oct 95 01:35 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id JAA03033; Tue, 17 Oct 1995 09:35:28 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: hackers@freebsd.org, core@freebsd.org Subject: Locale stuff: call for conclusion. In-reply-to: Your message of "Mon, 16 Oct 1995 20:06:14 EST." <199510170006.UAA25504@exalt.x.org> Date: Tue, 17 Oct 1995 09:35:26 +0100 Message-ID: <3031.813918926@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@freebsd.org Precedence: bulk (Core-members: Please send a vote to me on this) I belive that if not everything, then at least at lot, have been said, (sometimes even over and over again) but nothing has yet been done. I think we can also agree to the following things: 1. The crt0.s thing is a kludge, which should go away as soon as something more sane is implemented. 2. The crt0.s thing is actually a violation of some stds. 3. There is no harm to make the default case (unsetenv LANG & all that) be ISO-8859-1, and this will make a lot of people a lot more happy. It may not help Andrey much, but it is a large part of our userbase. 4. The right solution is to go through the programs, one by one and DTRT to them, if it makes sense. A lot of programs shouldn't care at all, cp(1) for instance, whereas other programs it does indeed matter, sort(1) for instance. Based on this I suggest that we: A) execute 3. B) execute 1. in the other sense of the word, and get crt0.s cleaned up. This will happen January 1st 1996 even if A) and/or C) hasn't happened. C) execute 4, as soon as anybody volounteer to do it. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. It will be some time yet before progress goes too far... (Poul Henningsen) From owner-freebsd-hackers Tue Oct 17 02:14:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA20122 for hackers-outgoing; Tue, 17 Oct 1995 02:14:39 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA20117 ; Tue, 17 Oct 1995 02:14:28 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA02971; Tue, 17 Oct 1995 19:11:18 +1000 Date: Tue, 17 Oct 1995 19:11:18 +1000 From: Bruce Evans Message-Id: <199510170911.TAA02971@godzilla.zeta.org.au> To: core@freebsd.org, hackers@freebsd.org, phk@critter.tfs.com Subject: Re: Locale stuff: call for conclusion. Sender: owner-hackers@freebsd.org Precedence: bulk >1. The crt0.s thing is a kludge, which should go away as soon as > something more sane is implemented. Agreed. >2. The crt0.s thing is actually a violation of some stds. See my previous mail about changing it to meet the C standard (change locale to the one specified by $LANG if $LANG is set, the restore everything specified by the standard - mainly alpha characters). >3. There is no harm to make the default case (unsetenv LANG & all that) > be ISO-8859-1, and this will make a lot of people a lot more happy. > It may not help Andrey much, but it is a large part of our userbase. Yes there is. It has more letters. >[More that I agree with]. >A) execute 3. Nope. >B) execute 1. in the other sense of the word, and get crt0.s cleaned up. > This will happen January 1st 1996 even if A) and/or C) hasn't happened. It can't be done sanely until after 3. Perhaps you meant 2096 :-). Bruce From owner-freebsd-hackers Tue Oct 17 02:25:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA20376 for hackers-outgoing; Tue, 17 Oct 1995 02:25:58 -0700 Received: from ccslinux.dlsu.edu.ph (root@linux1.dlsu.edu.ph [165.220.8.15]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA20316 for ; Tue, 17 Oct 1995 02:25:20 -0700 Received: by ccslinux.dlsu.edu.ph (Linux Smail3.1.28.1 #13) Sender: owner-hackers@FreeBSD.org Precedence: bulk id m0t586B-000A5TC; Tue, 17 Oct 95 17:14 GMT+0800 Date: Tue, 17 Oct 1995 17:14:15 +48000 From: Gavin Lim Subject: SunRPC To: hackers@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We currently have FreeBSD 2.0.5 installed on our LAN. We would be developing an application using SunRPC. We've downloaded SunRPC 4.0. Is this the latest version? Do we still have to install this, or does the FreeBSD package automatically include the RPC package during installation? Thanks! ============================================================================== Gavin Lim Gavin@linux1.dlsu.edu.ph ============================================================================== From owner-freebsd-hackers Tue Oct 17 02:33:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA20639 for hackers-outgoing; Tue, 17 Oct 1995 02:33:54 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA20609 ; Tue, 17 Oct 1995 02:33:31 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA03697; Tue, 17 Oct 1995 19:29:19 +1000 Date: Tue, 17 Oct 1995 19:29:19 +1000 From: Bruce Evans Message-Id: <199510170929.TAA03697@godzilla.zeta.org.au> To: bakul@netcom.com, terry@lambert.org Subject: Re: getdtablesize() broken? Cc: current@freefall.freebsd.org, hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >(BTW, If you don't change the limit, you will discover an off by >one bug: the default limit is 64 but you can only open 63 fds) I get 64. Perhaps you have a shell bug. >So I can do everything with fd > 255 except select(). This >happens because of this line in /sys/kern/sys_generic.c:select() > if (uap->nd > FD_SETSIZE) >It should be replaced with > if (uap->nd > p->fd->fd_nfiles) >It is this hardwired use of FD_SETSIZE *in* the kernel I am >bitching about. This would just give random errors or clobber the kernel stack. The limit is built in to the fd_set type. The FD_SETSIZE check just makes sure that all the bits fit in the kernel fd_set variables. The kernel needs to use dynamically allocated arrays to hold more bits, and different methods to access the bits... Bruce From owner-freebsd-hackers Tue Oct 17 03:30:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA21895 for hackers-outgoing; Tue, 17 Oct 1995 03:30:26 -0700 Received: from netcom5.netcom.com (bakul@netcom5.netcom.com [192.100.81.113]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA21888 ; Tue, 17 Oct 1995 03:30:23 -0700 Received: from localhost by netcom5.netcom.com (8.6.12/Netcom) id DAA04795; Tue, 17 Oct 1995 03:28:54 -0700 Message-Id: <199510171028.DAA04795@netcom5.netcom.com> To: Bruce Evans cc: terry@lambert.org, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? In-reply-to: Your message of "Tue, 17 Oct 95 19:29:19 +1000." <199510170929.TAA03697@godzilla.zeta.org.au> Date: Tue, 17 Oct 95 03:28:53 -0700 From: Bakul Shah Sender: owner-hackers@FreeBSD.org Precedence: bulk > I get 64. Perhaps you have a shell bug. Possible. Or may be there is an exra fd open. zsh seems to be the culprit here. > >It is this hardwired use of FD_SETSIZE *in* the kernel I am > >bitching about. > The limit is built in to the fd_set type. The FD_SETSIZE check > just makes sure that all the bits fit in the kernel fd_set > variables. The kernel needs to use dynamically allocated > arrays to hold more bits, and different methods to access the > bits... But of course! [My fix was partial but if you decide to banish FD_SETSIZE removing all use of fd_set follows -- I should never respond when I am half asleep; but that is when I get some free time :-(] Anyway, instead of fd_set the kernel needs to use just int* (and allocate enough ints). Instead of macros FD_{SET,CLR,ISSET,ZERO} it can use #define SET_BIT(n, p) ((p)[(n)/NFDBITS] |= (1 << ((n) % NFDBITS))) #define CLR_BIT(n, p) ((p)[(n)/NFDBITS] &= ~(1 << ((n) % NFDBITS))) #define ISSET_BIT(n, p) ((p)[(n)/NFDBITS] & (1 << ((n) % NFDBITS))) #define ZERO_BITS(n, p) bzero((char*)(p), \ howmany((n), NFDBITS) * sizeof(fd_mask)) [Going off on another tangent -- I wish we can start using inline functions instead of such odious macros -- even though inline is not ISO sanctioned every compiler worth its salt provides it] From owner-freebsd-hackers Tue Oct 17 03:49:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA22393 for hackers-outgoing; Tue, 17 Oct 1995 03:49:47 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id DAA22388 ; Tue, 17 Oct 1995 03:49:43 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t59aX-0003wxC; Tue, 17 Oct 95 03:49 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id LAA03166; Tue, 17 Oct 1995 11:49:39 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: Bakul Shah cc: Bruce Evans , terry@lambert.org, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? In-reply-to: Your message of "Tue, 17 Oct 1995 03:28:53 MST." <199510171028.DAA04795@netcom5.netcom.com> Date: Tue, 17 Oct 1995 11:49:39 +0100 Message-ID: <3164.813926979@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@FreeBSD.org Precedence: bulk > [Going off on another tangent -- I wish we can start using > inline functions instead of such odious macros -- even though > inline is not ISO sanctioned every compiler worth its salt > provides it] Wanna have a really good time: inline the syscalls... :-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. It will be some time yet before progress goes too far... (Poul Henningsen) From owner-freebsd-hackers Tue Oct 17 04:24:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA23133 for hackers-outgoing; Tue, 17 Oct 1995 04:24:15 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA23128 for ; Tue, 17 Oct 1995 04:24:13 -0700 Received: from exalt.x.org by expo.x.org id AA26199; Tue, 17 Oct 95 07:23:41 -0400 Received: from localhost by exalt.x.org id HAA08614; Tue, 17 Oct 1995 07:23:40 -0400 Message-Id: <199510171123.HAA08614@exalt.x.org> To: Terry Lambert Cc: hackers@freefall.FreeBSD.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Mon, 16 Oct 1995 19:04:08 EST. <199510170204.TAA26154@phaeton.artisoft.com> Organization: X Consortium Date: Tue, 17 Oct 1995 07:23:40 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > > I have the following by default in my environment : > > > > LANG=fr_FR.ISO_8859-1 > > LC_CTYPE=iso_8859_1 > > > > As soon as I switch LC_CTYPE to fr_FR.ISO_8859-1, all xterms started from > > this terminal will dump core (well, they won't because xterm is setuid > > root), each time. The signal is SEGV. > > Your xterm is improperly pretending to be internationalized. It's > pretending because there is bogus code in crt0.o that causes it to > call setlocale() when XPG/3 and XPG/4 both say it shouldn't. > > Either don't try to run in an international environment... or use > an xterm clone from contrib instead of xterm that really has been > internationalized. The xterm in question has been internationalized. However there appears to be an unanticipated side effect caused by both crt0.o and Xt calling setlocale, or it might be the LC_CTYPE=iso_8859_1, which *is* bogus for FreeBSD. If the user wants to set LC_CTYPE, it should be to a valid locale name for the system. (The LC_CTYPE=iso_8859_1 is a SunOS thing that was apparently copied from an example in a FAQ about how to get 8859-1 on SunOS.) Xedit in the R6 contrib has also been internationalized. Since it does not dump core on FreeBSD, with or without ENABLE_STARTUP_LOCALE, with or without the bogus LC_CTYPE, and the stack trace showed that it dumped core in xterm code, the problem may be that xterm assumes the startup locale will be C. -- Kaleb From owner-freebsd-hackers Tue Oct 17 04:26:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA23175 for hackers-outgoing; Tue, 17 Oct 1995 04:26:54 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA23170 for ; Tue, 17 Oct 1995 04:26:52 -0700 Received: from exalt.x.org by expo.x.org id AA26217; Tue, 17 Oct 95 07:26:21 -0400 Received: from localhost by exalt.x.org id HAA08625; Tue, 17 Oct 1995 07:26:20 -0400 Message-Id: <199510171126.HAA08625@exalt.x.org> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: hackers@freefall.FreeBSD.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Mon, 16 Oct 1995 23:45:15 EST. <199510162245.XAA27289@uriah.heep.sax.de> Organization: X Consortium Date: Tue, 17 Oct 1995 07:26:20 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > As Terry Lambert wrote: > > > > The problem with KOI-8 is that KOI-8 is a defacto standard, and is not > > accepted by international standards bodies. Mostly because the most > > popular BBS software in the area picked it up instead of 8859-9. > > The X Consortium finally agreed to accept koi8-r as a valid character > set/encoding. > > :-) I'm glad I read through all of my mail before replying to this. David Dawes' answer says it all! -- Kaleb KEITHLEY X Consortium From owner-freebsd-hackers Tue Oct 17 04:32:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA23303 for hackers-outgoing; Tue, 17 Oct 1995 04:32:53 -0700 Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA23295 for ; Tue, 17 Oct 1995 04:32:28 -0700 Received: (from root@localhost) by yarrina.connect.com.au with UUCP id VAA13864 (8.6.12/IDA-1.6 for hackers@freefall.freebsd.org); Tue, 17 Oct 1995 21:32:17 +1000 Received: from localhost.nemeton.com.au (giles@localhost.nemeton.com.au [127.0.0.1]) by nemeton.com.au (8.6.9/8.6.9) with SMTP id VAA09333 for ; Tue, 17 Oct 1995 21:15:17 +1000 Message-Id: <199510171115.VAA09333@nemeton.com.au> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-reply-to: Date: Tue, 17 Oct 1995 21:15:16 +1000 From: Giles Lean Apparently-To: hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.org Precedence: bulk On Mon, 16 Jan 1995 23:38:26 +0300 (MSK) =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > It is very bad karma to call setlocale from main for ctype-oriented > programs when chars size assumed <= 8bit. > Only crt0 is proper place for this things. crt0 is ABSOLUTELY NOT the place to try to "fix" this. The fix as Terry has explained very politely and in considerable detail is to localise individual programs. Blindly plugging in setlocale() is bad whether you plug it into main() or into crt0. Breaking ANSI and ISO standards conformance by plugging it into crt0 is just a bonus. :-( If there was a good easy solution to I18N don't you think *someone* in the standards groups would have pushed it? Or some proprietary system would have just *done* it, whether it was standard or not. This kludge would only be excusable if it *always* worked. If it works sometimes and you want to do it on your system, fine, but don't inflict it on the entire FreeBSD community. Fortunately the 'right' (standards conformant, clean-ish) solution can be implemented gradually. Further there is strong motivation for programs like editors and mailers to be localised and some programs like xterm are localised already. Since someone mentioned NetBSD I'll mention that it has very limited locale support so far, basically limited to the C locale and a couple or three non-English message catalogs. Giles From owner-freebsd-hackers Tue Oct 17 04:47:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA23452 for hackers-outgoing; Tue, 17 Oct 1995 04:47:07 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA23447 for ; Tue, 17 Oct 1995 04:47:05 -0700 Received: from exalt.x.org by expo.x.org id AA26398; Tue, 17 Oct 95 07:46:33 -0400 Received: from localhost by exalt.x.org id HAA08641; Tue, 17 Oct 1995 07:46:32 -0400 Message-Id: <199510171146.HAA08641@exalt.x.org> To: Bruce Evans Cc: hackers@freefall.FreeBSD.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Tue, 17 Oct 1995 17:21:33 EST. <199510170721.RAA31630@godzilla.zeta.org.au> Organization: X Consortium Date: Tue, 17 Oct 1995 07:46:31 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > >>Now all that goals are reached by 'setenv ENABLE_STARTUP_LOCALE' > >>and without any program modifications. > > >EXCEPT THAT VIOLATES ANSI/POSIX/ISO C, which stipulates that on the > >entry to main() the program must be in the C locale. People who use > >this hack on correctly written programs find that it breaks their > >programs in not very subtle ways, as you've already found with the > >i18n-aware xterm that XFree86 distributes. > > You don't have to use ENABLE_STARTUP_LOCALE if you want full > conformance. It's not whether *I* enable it or disable it. The issue is what happens to users do it. Like the XFree86 xterm. I cannot control what a user might do, and if setting ENABLE_STARTUP_LOCALE introduces a new state that the program did not anticipate, it causes problems. > >>It is especially essential when > >>program isn't FreeBSD native but comes from 3rd party, i.e. > >>ports area. Moreover, they can be reached on any remote system > >>too, includes freefall f.e. > > >Then perhaps the process of putting something into ports should include > >minimally localizing the program to set the locale to whatever the > >user has set in his or her LC_ALL, LC_CTYPE, or LANG environment variable. > > There aren't enough resources or interest. That's not a justification for non-compliance at the crt0.o level. As Terry and I have said, the people who use these programs and that usage is hampered by the lack of l10n/i18n, should be fixing those programs and sending the fixes back to the authors. > I think tradition is what requires the C locale to be strictly ASCII. Ah, the good old "that's the way we've always done it" argument. That dog won't hunt. For the most part the people who have always done it that way won't know the difference if the C locale has some minimal support for 8859-1. -- Kaleb From owner-freebsd-hackers Tue Oct 17 04:51:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA23518 for hackers-outgoing; Tue, 17 Oct 1995 04:51:07 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id EAA23512 for ; Tue, 17 Oct 1995 04:50:42 -0700 Received: by sovcom.kiae.su id AA23735 (5.65.kiae-1 ); Tue, 17 Oct 1995 14:33:22 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 14:33:22 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id OAA00485; Tue, 17 Oct 1995 14:31:34 +0300 To: David Dawes , joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@freebsd.org References: <199510170809.SAA07948@rf900.physics.usyd.edu.au> In-Reply-To: <199510170809.SAA07948@rf900.physics.usyd.edu.au>; from David Dawes at Tue, 17 Oct 1995 18:09:27 +1000 (EST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 14:31:34 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 14 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 656 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510170809.SAA07948@rf900.physics.usyd.edu.au> David Dawes writes: >If they ship Cyrillic fonts with their next release, they've indicated >(to me at least) that their preference is to use the ISO8859-5 encoding. Sigh. Why they not asking what preferences russsians have? Oh, well, it doesn't matter. They'll force all of them to 8859-5. :-) -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Tue Oct 17 04:56:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA23682 for hackers-outgoing; Tue, 17 Oct 1995 04:56:07 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id EAA23652 ; Tue, 17 Oct 1995 04:55:34 -0700 Received: by sovcom.kiae.su id AA23731 (5.65.kiae-1 ); Tue, 17 Oct 1995 14:33:21 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 14:33:21 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id OAA00467; Tue, 17 Oct 1995 14:26:18 +0300 To: core@freebsd.org, hackers@freebsd.org, Poul-Henning Kamp References: <3031.813918926@critter.tfs.com> In-Reply-To: <3031.813918926@critter.tfs.com>; from Poul-Henning Kamp at Tue, 17 Oct 1995 09:35:26 +0100 Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 14:26:18 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: Locale stuff: call for conclusion. Lines: 63 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2490 Sender: owner-hackers@freebsd.org Precedence: bulk In message <3031.813918926@critter.tfs.com> Poul-Henning Kamp writes: >(Core-members: Please send a vote to me on this) Here is some non-clarified things left. >I belive that if not everything, then at least at lot, have been said, >(sometimes even over and over again) but nothing has yet been done. >I think we can also agree to the following things: >1. The crt0.s thing is a kludge, which should go away as soon as > something more sane is implemented. >2. The crt0.s thing is actually a violation of some stds. >3. There is no harm to make the default case (unsetenv LANG & all that) > be ISO-8859-1, and this will make a lot of people a lot more happy. > It may not help Andrey much, but it is a large part of our userbase. I am happy with my hack right now and was against because it cause some problems for our userbase (i.e. when my hack is inactive), namely is*() macros do wrong things, but Terry point it as a 'feature', not a 'bug'. >4. The right solution is to go through the programs, one by one and DTRT > to them, if it makes sense. A lot of programs shouldn't care at all, > cp(1) for instance, whereas other programs it does indeed matter, > sort(1) for instance. >Based on this I suggest that we: >A) execute 3. I agree. >B) execute 1. in the other sense of the word, and get crt0.s cleaned up. > This will happen January 1st 1996 even if A) and/or C) hasn't happened. As you sayd > as something more sane is implemented. I am completely against of removing this hack when nothing sane implemented, so date doesn't play role here. >C) execute 4, as soon as anybody volounteer to do it. Well, as we voting, here additional issue (D), if you care of what sane can be implemented instead. By Terry idea we can switch from XPG/4 to XPG/3, it allows as safely use setlocale() in 8bit clean programs (not care of multibyte runic chars which isn't really used by Terry words). Currently all ports setlocale() soft and vi is very broken for runic chars, i.e. all such stuff assumes XPG/3 instead XPG/4 we have. Switching to XPG/3 allowing as to fix almost every 8bit clean program by simple adding setlocale(LC_ALL, "") into main(). -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Tue Oct 17 06:26:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA25113 for hackers-outgoing; Tue, 17 Oct 1995 06:26:36 -0700 Received: from deputy.pavilion.co.uk (deputy.pavilion.co.uk [194.193.24.33]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA25090 ; Tue, 17 Oct 1995 06:26:17 -0700 Received: from poolb48.pavilion.co.uk (poolb48.pavilion.co.uk [194.193.28.112]) by deputy.pavilion.co.uk (8.7/8.7) with SMTP id OAA16923; Tue, 17 Oct 1995 14:25:27 +0100 (BST) Date: Tue, 17 Oct 1995 14:25:27 +0100 (BST) Message-Id: <199510171325.OAA16923@deputy.pavilion.co.uk> X-Sender: aledm@mailhost.pavilion.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hackers@freebsd.org From: aledm@pavilion.co.uk (Aled Morris) Subject: ATAPI & triple CD-ROM Cc: hardware@freebsd.org X-Mailer: Sender: owner-hackers@freebsd.org Precedence: bulk Does anyone know if the ATAPI drivers (for IDE CD-ROM) support the Triple CD-ROM juke-box drives, as found in some Gateway 2000 high-end systems? Under DOS the three platters appear as three different drives, and the autochanger brings the "current" disk in as appropriate. Will the ATAPI driver be able to read the first platter as if it were a single disk drive? I am recommending FreeBSD to a friend with such a system, hence my ignorance of this area. Aled -- telephone +44 973 207987 From owner-freebsd-hackers Tue Oct 17 06:47:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA25465 for hackers-outgoing; Tue, 17 Oct 1995 06:47:29 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA25460 ; Tue, 17 Oct 1995 06:47:27 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t5CLl-0003wnC; Tue, 17 Oct 95 06:46 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id OAA03229; Tue, 17 Oct 1995 14:46:36 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: core@freebsd.org, hackers@freebsd.org Subject: Re: Locale stuff: call for conclusion. In-reply-to: Your message of "Tue, 17 Oct 1995 14:26:18 +0300." Date: Tue, 17 Oct 1995 14:46:35 +0100 Message-ID: <3227.813937595@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@freebsd.org Precedence: bulk > >C) execute 4, as soon as anybody volounteer to do it. > > Well, as we voting, here additional issue (D), if you care > of what sane can be implemented instead. By Terry idea we can > switch from XPG/4 to XPG/3, it allows as safely use setlocale() > in 8bit clean programs (not care of multibyte runic chars which > isn't really used by Terry words). I think that is a very good idea, but I only see it as a different way of doing something "sane". It doesn't affect the issue at hand which way we do it, only THAT we do it. I would vote for it btw. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. It will be some time yet before progress goes too far... (Poul Henningsen) From owner-freebsd-hackers Tue Oct 17 06:54:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA25615 for hackers-outgoing; Tue, 17 Oct 1995 06:54:08 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA25610 for ; Tue, 17 Oct 1995 06:54:05 -0700 Received: from exalt.x.org by expo.x.org id AA00350; Tue, 17 Oct 95 09:53:33 -0400 Received: from localhost by exalt.x.org id JAA08843; Tue, 17 Oct 1995 09:53:32 -0400 Message-Id: <199510171353.JAA08843@exalt.x.org> To: ache@astral.msk.su Cc: hackers@freefall.FreeBSD.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Tue, 17 Oct 1995 14:31:34 EST. Organization: X Consortium Date: Tue, 17 Oct 1995 09:53:31 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > In message <199510170809.SAA07948@rf900.physics.usyd.edu.au> David > Dawes writes: > > >If they ship Cyrillic fonts with their next release, they've indicated > >(to me at least) that their preference is to use the ISO8859-5 encoding. > > Sigh. Why they not asking what preferences russsians have? Because the X Consortium is a Standards Body. When there is an existing standard for something we prefer to follow it (Like RFC 821/822). In the face of a "real" standard, a de facto standard doesn't count. > Oh, well, it doesn't matter. They'll force all of them to 8859-5. :-) Why do you say this? My impression is that most people prefer precompiled binaries from XFree86 over building from X Consortium source. XFree86 provides KOI8-R encoded fonts and locale support. Users can choose KOI8-R or ISO8859-5 as long as there are fonts for both encodings. Nobody is "forcing" anyone to do anything. -- Kaleb KEITHLEY X Consortium From owner-freebsd-hackers Tue Oct 17 06:59:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA25728 for hackers-outgoing; Tue, 17 Oct 1995 06:59:44 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA25722 ; Tue, 17 Oct 1995 06:59:41 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA13673; Tue, 17 Oct 1995 06:59:34 -0700 To: ports@freefall.FreeBSD.org cc: hackers@freefall.FreeBSD.org Subject: Pending crisis in packages/All/... Date: Tue, 17 Oct 1995 06:59:33 -0700 Message-ID: <13671.813938373@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk Aw foo, I knew it was too simple to be true.. The packages/All directory has proven to be a life saver in implementing all the chained-add stuff I've been doing for pkg_add (e.g. pkg_add will now load any dependent packages, via path or URL) and sysinstall will be using it too for all the package loading it does. All/ is nice because it flattens the hierarchy out and saves you what would otherwise be a lot of annoying searching ("searching" an FTP server is no fun in particular, let me tell you!) and anyway it's generally just a handy thing and life would be wonderful except for one little tiny annoying problem that just occured to me: mksiofs can't hack it. mkisofs breaks badly on a directory containing as many symlinks as the packages/All directory does, and last time I was not able to get packages/All on the CDROM because of it. To not be able to do auto-package adding off a CDROM would be a bad thing, yet I don't see any immediate solution. mkisofs is a real ball of fur that you would not want to get into, but just in case anyone really feels the urge to see what it is I'm talking about, you can do it trivially by following these steps: Use mkisofs to create a ISOFS filesystem image of the packages/All tree. Don't ask me for the flags to mkisofs, I can't remember all the relevant ones at the moment. You'll find them since they're all kind of non-optional anyway.. :) Use vnconfig to point /dev/vn0 at the created image. `mount -t cd9660 /dev/vn0 /mnt' or something to that effect. You'll see that the Rockridge information for packages/All is spammed pretty good and not very usable. The way I see it, we have a few options: 1. I can try to find some different mastering software to use and somehow get the FreeBSD distribution trees to a machine that supports it. Ugh. 2. Fix mkisofs. Ugh. 3. Reshuffle or eliminate packages/All to work around the bug. Ugh. As you can see, I'm greatly enamoured of all these alternatives.. :-) Thoughts? Jordan From owner-freebsd-hackers Tue Oct 17 07:09:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA25953 for hackers-outgoing; Tue, 17 Oct 1995 07:09:07 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA25947 ; Tue, 17 Oct 1995 07:09:03 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t5ChR-0003vmC; Tue, 17 Oct 95 07:09 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id PAA03345; Tue, 17 Oct 1995 15:09:02 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: "Jordan K. Hubbard" cc: ports@freefall.FreeBSD.org, hackers@freefall.FreeBSD.org Subject: Re: Pending crisis in packages/All/... In-reply-to: Your message of "Tue, 17 Oct 1995 06:59:33 MST." <13671.813938373@time.cdrom.com> Date: Tue, 17 Oct 1995 15:09:02 +0100 Message-ID: <3343.813938942@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@FreeBSD.org Precedence: bulk > mksiofs can't hack it. > > mkisofs breaks badly on a directory containing as many symlinks as the > packages/All directory does, and last time I was not able to get > packages/All on the CDROM because of it. To not be able to do > auto-package adding off a CDROM would be a bad thing, yet I don't see Turn it around then: Put the packages in packages/All and the symlinks in packages/networking &c ??? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. It will be some time yet before progress goes too far... (Poul Henningsen) From owner-freebsd-hackers Tue Oct 17 07:25:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA26309 for hackers-outgoing; Tue, 17 Oct 1995 07:25:35 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA26299 ; Tue, 17 Oct 1995 07:25:31 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id HAA21039; Tue, 17 Oct 1995 07:25:21 -0700 To: Poul-Henning Kamp cc: ports@freefall.FreeBSD.org, hackers@freefall.FreeBSD.org Subject: Re: Pending crisis in packages/All/... In-reply-to: Your message of "Tue, 17 Oct 1995 15:09:02 BST." <3343.813938942@critter.tfs.com> Date: Tue, 17 Oct 1995 07:25:21 -0700 Message-ID: <21037.813939921@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > Turn it around then: Put the packages in packages/All and the symlinks > in packages/networking &c ??? Uh, sorry - I mis-explained things badly. It IS that way now. It's actually having all those *files* in one directory that breaks mkisofs, not just a lot of symlinks. Jordan From owner-freebsd-hackers Tue Oct 17 07:31:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA26508 for hackers-outgoing; Tue, 17 Oct 1995 07:31:48 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA26503 ; Tue, 17 Oct 1995 07:31:45 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t5D3Q-0003vnC; Tue, 17 Oct 95 07:31 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id PAA03387; Tue, 17 Oct 1995 15:31:44 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: "Jordan K. Hubbard" cc: ports@freefall.FreeBSD.org, hackers@freefall.FreeBSD.org Subject: Re: Pending crisis in packages/All/... In-reply-to: Your message of "Tue, 17 Oct 1995 07:25:21 MST." <21037.813939921@time.cdrom.com> Date: Tue, 17 Oct 1995 15:31:43 +0100 Message-ID: <3385.813940303@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@FreeBSD.org Precedence: bulk > > Turn it around then: Put the packages in packages/All and the symlinks > > in packages/networking &c ??? > > Uh, sorry - I mis-explained things badly. > > It IS that way now. It's actually having all those *files* in one > directory that breaks mkisofs, not just a lot of symlinks. Hmm, packages/A-J packages/K-S packages/T-Z ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. It will be some time yet before progress goes too far... (Poul Henningsen) From owner-freebsd-hackers Tue Oct 17 07:33:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA26614 for hackers-outgoing; Tue, 17 Oct 1995 07:33:45 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA26606 ; Tue, 17 Oct 1995 07:33:38 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id HAA23773; Tue, 17 Oct 1995 07:33:05 -0700 To: Poul-Henning Kamp cc: ports@freefall.FreeBSD.org, hackers@freefall.FreeBSD.org Subject: Re: Pending crisis in packages/All/... In-reply-to: Your message of "Tue, 17 Oct 1995 15:31:43 BST." <3385.813940303@critter.tfs.com> Date: Tue, 17 Oct 1995 07:33:05 -0700 Message-ID: <23771.813940385@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > Hmm, > packages/A-J > packages/K-S > packages/T-Z > ? I knew I could count on you for the really evil suggestions.. :-) Jordan From owner-freebsd-hackers Tue Oct 17 07:36:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA26720 for hackers-outgoing; Tue, 17 Oct 1995 07:36:13 -0700 Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA26711 for ; Tue, 17 Oct 1995 07:36:06 -0700 Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id AAA09365 for hackers@freebsd.org; Wed, 18 Oct 1995 00:36:04 +1000 From: David Dawes Message-Id: <199510171436.AAA09365@rf900.physics.usyd.edu.au> Subject: Very slot TCP connections? To: hackers@freebsd.org Date: Wed, 18 Oct 1995 00:36:03 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 922 Sender: owner-hackers@freebsd.org Precedence: bulk I've recently noticed a problem when attempting to transfer data via ftp from a site (ftp.usyd.edu.au, which is running Solaris 2.3 or 2.4, and using wuftpd 2.4). My FreeBSD 2.0.5 machine is connected to the net via the user-mode ppp dialup to an Annex terminal server. The ftp site I'm connecting to is local to the Annex side. The problem is that transfers are painfully slow -- a directory listing comes through at about one line every 30 seconds. I haven't noticed this problem when using ftp to other machines, and I don't see the problem if I connect from a machine local to that ftp server (but I don't have any FreeBSD 2.0.5 machines on that side). I've got tcp_extensions set to NO. I've also found http connections to that site to be unusably slow, although if I go via a proxy at the remote end it is OK. Anyone have any ideas about this or about how I could go about tracing what the problem is? David From owner-freebsd-hackers Tue Oct 17 07:46:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA27067 for hackers-outgoing; Tue, 17 Oct 1995 07:46:27 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA27061 ; Tue, 17 Oct 1995 07:46:20 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t5DHW-0003vpC; Tue, 17 Oct 95 07:46 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id PAA03440; Tue, 17 Oct 1995 15:46:19 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: "Jordan K. Hubbard" cc: ports@freefall.FreeBSD.org, hackers@freefall.FreeBSD.org Subject: Re: Pending crisis in packages/All/... In-reply-to: Your message of "Tue, 17 Oct 1995 07:33:05 MST." <23771.813940385@time.cdrom.com> Date: Tue, 17 Oct 1995 15:46:18 +0100 Message-ID: <3438.813941178@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@FreeBSD.org Precedence: bulk > > Hmm, > > packages/A-J > > packages/K-S > > packages/T-Z > > ? > > I knew I could count on you for the really evil suggestions.. :-) Sorted on the 2nd letter of course to distribute the x11 stuff evenly... :-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. It will be some time yet before progress goes too far... (Poul Henningsen) From owner-freebsd-hackers Tue Oct 17 08:12:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA27857 for hackers-outgoing; Tue, 17 Oct 1995 08:12:30 -0700 Received: from peter.cs.andrews.edu (root@peter.cs.andrews.edu [143.207.1.4]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA27852 for ; Tue, 17 Oct 1995 08:12:27 -0700 Received: from edmund (edmund.cs.andrews.edu) by peter.cs.andrews.edu (5.x/SMI-SVR4) id AA16313; Tue, 17 Oct 1995 11:12:23 -0400 From: gillham@andrews.edu (Andrew Gillham) Received: by edmund (5.x) id AA24607; Tue, 17 Oct 1995 11:12:22 -0400 Message-Id: <9510171512.AA24607@edmund> Subject: Stability questions... To: freebsd-hackers@freebsd.org Date: Tue, 17 Oct 1995 11:12:21 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk Apologies if this is the wrong mailing list. I installed FreeBSD 2.0.5-RELEASE over the weekend, and I have been having problems with it. What I am seeing is "cc1 interrupted by signal 11" or similar when I am trying to compile a kernel. Restarting make will eventually get it all built though. Is this a known problem with 2.0.5-RELEASE, or is my hardware flakey? My hardware: ASUS SP3G w/AMD DX4/100 32MB NCR PCI SCSI Micropolis MC2217 3c509 (not a 'b') ATI GUP ISA I have been running NetBSD on this box without any problems. Also, I supped freebsd-current onto my NetBSD NFS server, and tried building it. I was able to build a kernel and /sbin/* (by restarting make whenever cc1 got a SEGV), and rebooted with the new kernel. This new kernel didn't appear to have the SEGV problem, but I'm not 100% sure, as something else broke. After a few minutes of compiling (on the NFS mount) the kernel says "Biodone: buffer already done" or something and hangs my compile. (sorry for the not exact errors, but I'm at work, and the PCs are at home) Accessing the NFS mountpoint will hang my shell, but I can still halt the box from another console. Any ideas? Should I be trying to update to 2.1-current instead of 2.2-current? (how would I do that? I just ask for 'current' via sup.) Thanks for any assistance. -Andrew From owner-freebsd-hackers Tue Oct 17 08:33:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA28394 for hackers-outgoing; Tue, 17 Oct 1995 08:33:49 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA28388 for ; Tue, 17 Oct 1995 08:33:45 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id IAA27834; Tue, 17 Oct 1995 08:33:27 -0700 To: gillham@andrews.edu (Andrew Gillham) cc: freebsd-hackers@freebsd.org Subject: Re: Stability questions... In-reply-to: Your message of "Tue, 17 Oct 1995 11:12:21 EDT." <9510171512.AA24607@edmund> Date: Tue, 17 Oct 1995 08:33:26 -0700 Message-ID: <27826.813944006@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > by signal 11" or similar when I am trying to compile a kernel. > Restarting make will eventually get it all built though. Is this a > known problem with 2.0.5-RELEASE, or is my hardware flakey? This has been a sign of hardware flakeyness or misconfiguration in every instance I've ever seen, that's all I can really say. Jordan From owner-freebsd-hackers Tue Oct 17 08:43:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA28971 for hackers-outgoing; Tue, 17 Oct 1995 08:43:50 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA28950 ; Tue, 17 Oct 1995 08:43:37 -0700 Received: by Sysiphos id AA25349 (5.67b/IDA-1.5); Tue, 17 Oct 1995 16:42:13 +0100 Message-Id: <199510171542.AA25349@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Tue, 17 Oct 1995 16:42:13 +0100 In-Reply-To: gillham@andrews.edu (Andrew Gillham) "Stability questions..." (Oct 17, 11:12) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: gillham@andrews.edu (Andrew Gillham) Subject: Re: Stability questions... Cc: hackers@freebsd.org, current@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk On Oct 17, 11:12, Andrew Gillham wrote: } Subject: Stability questions... } sure, as something else broke. After a few minutes of compiling (on the } NFS mount) the kernel says "Biodone: buffer already done" or something } and hangs my compile. (sorry for the not exact errors, but I'm at } work, and the PCs are at home) Accessing the NFS mountpoint will hang } my shell, but I can still halt the box from another console. The same problem exists for me since October 5th ... I had sent a message on this topic some 10 days ago. There are lot's of "biodone: buffer already done" messages on the console, and the system hangs after some time (and is unable to unmount the file systems, if I try to reboot in time). (I had reported, that a "tail" of some file on a NFS mounted file system hung in a kernel wait, while a "cat" of the same file did work just fine on another virtual console ...) I'm running -current on my development system, and have not tried -stable. Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-hackers Tue Oct 17 08:52:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA29288 for hackers-outgoing; Tue, 17 Oct 1995 08:52:46 -0700 Received: from cioeserv.cioe.com (cioeserv.cioe.com [204.120.165.59]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA29281 for ; Tue, 17 Oct 1995 08:52:38 -0700 Received: (from steve@localhost) by cioeserv.cioe.com (8.6.12/8.6.9) id KAA17299; Tue, 17 Oct 1995 10:43:20 GMT Date: Tue, 17 Oct 1995 10:43:20 GMT From: Steve Ames Message-Id: <199510171043.KAA17299@cioeserv.cioe.com> To: jkh@time.cdrom.com Subject: Re: Stability questions... Cc: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk I had that same problem with some Pentium-90s that the powers that be threw at me. Disabling the external cache solved the sig 11s at the cost of some speed... -Steve From owner-freebsd-hackers Tue Oct 17 09:16:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA29788 for hackers-outgoing; Tue, 17 Oct 1995 09:16:56 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA29783 for ; Tue, 17 Oct 1995 09:16:51 -0700 Received: from exalt.x.org by expo.x.org id AA05129; Tue, 17 Oct 95 12:16:19 -0400 Received: from localhost by exalt.x.org id MAA09068; Tue, 17 Oct 1995 12:16:12 -0400 Message-Id: <199510171616.MAA09068@exalt.x.org> To: Terry Lambert Cc: hackers@freefall.FreeBSD.org Subject: Re: getdtablesize() broken? In-Reply-To: Your message of Mon, 16 Oct 1995 19:10:53 EST. <199510170210.TAA26181@phaeton.artisoft.com> Organization: X Consortium Date: Tue, 17 Oct 1995 12:16:11 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > > >Poll, anyone? > > > > >Poll is inferior to select, > > > > Debatable. > > Not. 8-). > > > >both because of the 10ms limit on timeout > > >resoloution > > > > Man pages only say that if the host does not support millisecond > > accuracy then the value is rounded up to the nearest legal value > > available. > > 10ms is the argument resoloution. Do you mean 1000 usec (1000usec == 1msec)? All the man pages I have say the timeout parameter specifies milliseconds (ms or msec). None say anything about 10ms granularity. Spec1170 is the first document I've seen that specs poll, for that matter it's also the first I've seen that documents select. The spec for both poll and select says: If the requested timeout interval requires a finer granularity than the implementation supports, the actual timeout interval will be rounded up to the next supported value. > On Solaris, it's 10ms, ... Perhaps Sun's implementation! There is no reason why a FreeBSD implmentation of poll could not have granularity of one ms/msec/millisecond, so long as there's nothing in FreeBSD itself that prevents it from achieving that granularity. Seems like if select can do 4usec then poll should have no difficulty achieving 1msec. > ... while select() > is till 4uS. select() wins. 8-). How can that be? I can specify all the way down to 1usec and the system will round up. On Solaris select(3) calls poll(2) (there is no select(2)) This suggests that select on Solaris will actually round all the way up to 1000usec (1msec) or that select can somehow trick poll into using finer granularity than it would otherwise! The fact that select(2) has a granularity as small as 4 usec (microseconds) would seem to have little or no bearing when you're doing actual polling. Both are specified as returning as soon as data is available on one (or more) of the file descriptors. > > That hasn't been my experience. poll(0, NULL, 10000); waits 10 seconds > > on SunOS, all SVR4-en I have here, HPUX, and AIX. In fact in SVR4 > > select(3) is implemented using poll(2). > > That's a bug in SVR4. SVR4 is broken and bogus in many, many ways. > > That's why this is "FreeBSD" instead of "FreeSVR4". 8-). Non sequitur! We're talking about whether poll can be used like select for fine grain delays. You assert that poll doesn't wait when nfds==0. I say that assertion is false based on empirical evidence. Man pages and Spec1170 offer nothing to suggest otherwise. > > In theory poll could be more efficient because there's less bit > > twiddling to do and unless you're polling thousands of files poll > > needs to transfer far less data to the kernel address space. Back > > in the days of 1.1.5.1 I started to look at what it would take to > > add poll. Maybe I'll look again. > > I agree that it could, though I'd want a timeval struct instead of an > integer time value That wouldn't be compliant with the definition of poll in Spec1170. That would be a Bad Thing. All you're really saying is you want to be able to specify a delay shorter than 1000usec (1msec) or longer than INT_MAX (or MAXINT) milliseconds or shorter than 1000 usec (1msec). 24 days isn't long enough for you? :-) As I said, if you're doing "real" polling, I don't believe minimum granularity is really an issue.If you're doing some sort of round-robin busy looping with non-blocking I/O you could probably call poll with a zero msec timeout; then the time overhead of the syscall would be the minimum delay. If that's still not adequate then you need a new function upoll(). :-) > implicitly limited to a 10ms resoloution by its units. As above, I believe you mean 1000 usec? -- Kaleb From owner-freebsd-hackers Tue Oct 17 09:17:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA29819 for hackers-outgoing; Tue, 17 Oct 1995 09:17:43 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA29814 for ; Tue, 17 Oct 1995 09:17:41 -0700 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id MAA04174; Tue, 17 Oct 1995 12:20:37 -0400 Date: Tue, 17 Oct 1995 12:20:37 -0400 From: Charles Henrich Message-Id: <199510171620.MAA04174@crh.cl.msu.edu> To: jkh@time.cdrom.com, freebsd-hackers@freebsd.org Subject: Re: Pending crisis in packages/All/... Newsgroups: lists.freebsd.hackers References: <460je1$k8u@msunews.cl.msu.edu> X-Newsreader: NN version 6.5.0 #3 (NOV) Sender: owner-hackers@freebsd.org Precedence: bulk In lists.freebsd.hackers you write: > mksiofs can't hack it. Is this the latest mkisofs? (1.04), there are some comments in the Changelog that refer to symlinks, perhaps he also fixed a bug or two? -Crh -- Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-hackers Tue Oct 17 09:35:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA00429 for hackers-outgoing; Tue, 17 Oct 1995 09:35:10 -0700 Received: from seattle.polstra.com (seattle.polstra.com [198.211.214.4]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA00412 for ; Tue, 17 Oct 1995 09:34:58 -0700 Received: by seattle.polstra.com (Smail3.1.28.1 #5) id m0t5EyY-000077C; Tue, 17 Oct 95 09:34 PDT Message-Id: Date: Tue, 17 Oct 95 09:34 PDT From: jdp@polstra.com (John Polstra) To: freebsd-hackers@polstra.com Subject: Re: getdtablesize() broken? Sender: owner-hackers@FreeBSD.org Precedence: bulk In <199510170210.TAA26181@phaeton.artisoft.com>, Terry Lambert wrote: > > >Poll, anyone? > > > > >Poll is inferior to select, > > > > Debatable. > > Not. 8-). > > > >both because of the 10ms limit on timeout > > >resoloution > > > > Man pages only say that if the host does not support millisecond > > accuracy then the value is rounded up to the nearest legal value > > available. > > 10ms is the argument resoloution. On Solaris, it's 10ms, while select() > is till 4uS. select() wins. 8-). Why do you say "10ms is the argument resoloution"? The man pages explicitly say that the timeout is specified in milliseconds. Simple tests indicate that the man pages are accurate. What is the basis for your claim? > > [Responding to a claim by Terry that poll doesn't support simple timed > > waits not involving file descriptors] > > > > That hasn't been my experience. poll(0, NULL, 10000); waits 10 seconds > > on SunOS, all SVR4-en I have here, HPUX, and AIX; however Digital Unix's > > poll looses. In fact in SVR4 select(3) is implemented using poll(2). > > That's a bug in SVR4. SVR4 is broken and bogus in many, many ways. You're confusing me. First you say that poll is no good because it doesn't support simple timed waits. Then somebody points out that you were wrong, and poll does in fact support that. So then you say that polls which work that way are broken. Poll is broken, because it fails to exhibit the broken behavior which you originally claimed it had? Have I got this right? > SVR4 is broken and bogus in many, many ways. Of course SVR4 is broken. FreeBSD is broken. Linux is broken. VMS is broken. They're all broken, in one way or another. That doesn't automatically mean that their every feature is broken. I've used both select and poll in many, many applications. They both got the job done for me. John Polstra jdp@polstra.com Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Tue Oct 17 10:04:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA00931 for hackers-outgoing; Tue, 17 Oct 1995 10:04:59 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA00925 for ; Tue, 17 Oct 1995 10:04:53 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id NAA21892; Tue, 17 Oct 1995 13:18:18 -0400 Date: Tue, 17 Oct 1995 13:18:18 -0400 Message-Id: <199510171718.NAA21892@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: davidg@root.com From: dennis@etinc.com (dennis) Subject: Shutdown Procedure Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk I found the bug in my driver that caused the problem in shutdown...now that I've looked closely at the procedures I have a question or two. I noticed that if_ed.c calls ed_registerdev() at the beginning of the probe routine rather than after if_attach() as in previous releases and as some other drivers do. I've also noticed that the device is in the table even if it is disabled. What is the reason for the change? Who/what uses the kdc_state information, and what is the impact of a device being IDLE or BUSY? Thanks, Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Tue Oct 17 10:07:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA01033 for hackers-outgoing; Tue, 17 Oct 1995 10:07:44 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA01028 for ; Tue, 17 Oct 1995 10:07:42 -0700 Received: from exalt.x.org by expo.x.org id AA06433; Tue, 17 Oct 95 13:07:10 -0400 Received: from localhost by exalt.x.org id NAA09860; Tue, 17 Oct 1995 13:07:09 -0400 Message-Id: <199510171707.NAA09860@exalt.x.org> To: jdp@polstra.com (John Polstra) Cc: hackers@freefall.FreeBSD.org Subject: Re: getdtablesize() broken? In-Reply-To: Your message of Tue, 17 Oct 1995 09:34:00 EST. Organization: X Consortium Date: Tue, 17 Oct 1995 13:07:07 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > > > > [Responding to a claim by Terry that poll doesn't support simple timed > > > waits not involving file descriptors] > > > > > > That hasn't been my experience. poll(0, NULL, 10000); waits 10 seconds > > > on SunOS, all SVR4-en I have here, HPUX, and AIX; however Digital Unix's > > > poll looses. In fact in SVR4 select(3) is implemented using poll(2). > > > > That's a bug in SVR4. SVR4 is broken and bogus in many, many ways. > > You're confusing me. First you say that poll is no good because it > doesn't support simple timed waits. Then somebody points out that you > were wrong, and poll does in fact support that. So then you say that > polls which work that way are broken. > I think Terry simply that it was a bug that select was implemented using poll on SVR4. -- Kaleb From owner-freebsd-hackers Tue Oct 17 10:43:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA01509 for hackers-outgoing; Tue, 17 Oct 1995 10:43:40 -0700 Received: from peter.cs.andrews.edu (root@peter.cs.andrews.edu [143.207.1.4]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA01502 for ; Tue, 17 Oct 1995 10:43:37 -0700 Received: from edmund (edmund.cs.andrews.edu) by peter.cs.andrews.edu (5.x/SMI-SVR4) id AA02540; Tue, 17 Oct 1995 13:43:31 -0400 From: gillham@andrews.edu (Andrew Gillham) Received: by edmund (5.x) id AA14344; Tue, 17 Oct 1995 13:43:31 -0400 Message-Id: <9510171743.AA14344@edmund> Subject: Re: Stability questions... To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 17 Oct 1995 13:43:30 -0400 (EDT) Cc: freebsd-hackers@freebsd.org In-Reply-To: <27826.813944006@time.cdrom.com> from "Jordan K. Hubbard" at Oct 17, 95 08:33:26 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk > > by signal 11" or similar when I am trying to compile a kernel. > > Restarting make will eventually get it all built though. Is this a > > known problem with 2.0.5-RELEASE, or is my hardware flakey? > > This has been a sign of hardware flakeyness or misconfiguration > in every instance I've ever seen, that's all I can really say. > > Jordan So... What do you suggest? Disabling the hardware cache? Why would the 2.2-CURRENT and NetBSD kernels not have the problem? I'm fairly sure that 2.2-CURRENT (as of saturday) _doesn't_ have the SEGV problem, just the biodone problem. I am willing to accept that it is my ASUS if nobody else has seen the problem. I will try it after disabling my cache, etc. (i.e. load BIOS default) -Andrew From owner-freebsd-hackers Tue Oct 17 10:43:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA01536 for hackers-outgoing; Tue, 17 Oct 1995 10:43:47 -0700 Received: from netcom23.netcom.com (bakul@netcom23.netcom.com [192.100.81.137]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA01527 ; Tue, 17 Oct 1995 10:43:44 -0700 Received: from localhost by netcom23.netcom.com (8.6.12/Netcom) id KAA17733; Tue, 17 Oct 1995 10:42:27 -0700 Message-Id: <199510171742.KAA17733@netcom23.netcom.com> To: "Jordan K. Hubbard" cc: ports@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: Pending crisis in packages/All/... In-reply-to: Your message of "Tue, 17 Oct 95 06:59:33 PDT." <13671.813938373@time.cdrom.com> Date: Tue, 17 Oct 95 10:42:24 -0700 From: Bakul Shah Sender: owner-hackers@FreeBSD.org Precedence: bulk Have your tools auto-search starting from the specified dir. Thus you have, for example, All/or/nothing All/or/else All/factory All/ah etc. and if pkg foo depends on bar, and All is the specified distribution dir, pkg_add walks down the All/ tree until it finds foo. You can use some conventions to group things logically. From owner-freebsd-hackers Tue Oct 17 10:44:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA01626 for hackers-outgoing; Tue, 17 Oct 1995 10:44:42 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA01615 for ; Tue, 17 Oct 1995 10:44:17 -0700 Received: by sovcom.kiae.su id AA16264 (5.65.kiae-1 ); Tue, 17 Oct 1995 20:37:50 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 20:37:50 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id UAA01279; Tue, 17 Oct 1995 20:29:46 +0300 To: "Kaleb S. KEITHLEY" Cc: hackers@freefall.FreeBSD.org References: <199510171353.JAA08843@exalt.x.org> In-Reply-To: <199510171353.JAA08843@exalt.x.org>; from "Kaleb S. KEITHLEY" at Tue, 17 Oct 1995 09:53:31 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 20:29:46 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 27 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1127 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510171353.JAA08843@exalt.x.org> Kaleb S. KEITHLEY writes: >> In message <199510170809.SAA07948@rf900.physics.usyd.edu.au> David >> Dawes writes: >> >> >If they ship Cyrillic fonts with their next release, they've indicated >> >(to me at least) that their preference is to use the ISO8859-5 encoding. >> >> Sigh. Why they not asking what preferences russsians have? >Because the X Consortium is a Standards Body. When there is an existing >standard for something we prefer to follow it (Like RFC 821/822). In the >face of a "real" standard, a de facto standard doesn't count. What do you mean by "real"? KOI8-R has two references now, they are RFC 1489 (description) and RFC 1700 (registration as valid MIME charset name). Is it enough for "real"? If you mean only ISO by "real", why you refer RFC 822? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Tue Oct 17 11:03:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA02017 for hackers-outgoing; Tue, 17 Oct 1995 11:03:05 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA02012 ; Tue, 17 Oct 1995 11:03:02 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA27890; Tue, 17 Oct 1995 10:55:49 -0700 From: Terry Lambert Message-Id: <199510171755.KAA27890@phaeton.artisoft.com> Subject: Re: getdtablesize() broken? To: bakul@netcom.com (Bakul Shah) Date: Tue, 17 Oct 1995 10:55:49 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, current@freefall.freebsd.org, hackers@freefall.freebsd.org In-Reply-To: <199510171028.DAA04795@netcom5.netcom.com> from "Bakul Shah" at Oct 17, 95 03:28:53 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2286 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > > I get 64. Perhaps you have a shell bug. > > Possible. Or may be there is an exra fd open. zsh seems to be > the culprit here. > > > >It is this hardwired use of FD_SETSIZE *in* the kernel I am > > >bitching about. > > > The limit is built in to the fd_set type. The FD_SETSIZE check > > just makes sure that all the bits fit in the kernel fd_set > > variables. The kernel needs to use dynamically allocated > > arrays to hold more bits, and different methods to access the > > bits... > > But of course! [My fix was partial but if you decide to > banish FD_SETSIZE removing all use of fd_set follows -- I > should never respond when I am half asleep; but that is when > I get some free time :-(] Anyway, instead of fd_set the > kernel needs to use just int* (and allocate enough ints). > Instead of macros FD_{SET,CLR,ISSET,ZERO} it can use > > #define SET_BIT(n, p) ((p)[(n)/NFDBITS] |= (1 << ((n) % NFDBITS))) > #define CLR_BIT(n, p) ((p)[(n)/NFDBITS] &= ~(1 << ((n) % NFDBITS))) > #define ISSET_BIT(n, p) ((p)[(n)/NFDBITS] & (1 << ((n) % NFDBITS))) > #define ZERO_BITS(n, p) bzero((char*)(p), \ > howmany((n), NFDBITS) * sizeof(fd_mask)) I assume (well, you assume 8-)) the size of the bit vector array type in the declaration is sizeof(x) == NFDBITS? This leads to: #define MAX_BIT(x) (sizeof(x)/NFDBITS) I don't see where this massive amount of runtime work is really worth it. /usr/unclude/sys/types.h has the forllowing in it: #ifndef FD_SETSIZE #define FD_SETSIZE 256 #endif meaning you can option it higher in the kernel and you can #define it higher before including . > [Going off on another tangent -- I wish we can start using > inline functions instead of such odious macros -- even though > inline is not ISO sanctioned every compiler worth its salt > provides it] It should be an option. But like having C equivalents for asm library routines or compiler inlines, it needs to be allowed to be turned off. Most ports do not start out self hosting until quite some way down the road, and the reason such things are avoided (or replicated) is to ease porting requirements. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 11:10:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA02293 for hackers-outgoing; Tue, 17 Oct 1995 11:10:39 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA02288 for ; Tue, 17 Oct 1995 11:10:37 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA27915; Tue, 17 Oct 1995 11:02:29 -0700 From: Terry Lambert Message-Id: <199510171802.LAA27915@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 17 Oct 1995 11:02:29 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199510162248.XAA27324@uriah.heep.sax.de> from "J Wunsch" at Oct 16, 95 11:48:31 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 783 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > > What you mean by majority? Russian users amount is comparable > > > with all european users, why not extend default table to KOI8-R > > > instead? > > > > Because post ANSI 3.64 terminal control codes reserve 0x80..0x9f and > > KOI8-R does not respect this international standard? > > Terry, before giving public statements, please look at the character > set. It's included in the latest public fix from XConsortium and in > XFree86 3.1.2, so you shouldn't have a hard time to find something > about it. It has characters "which may be omitted" in the range 0x80-0x9f. Perhaps the font has chosen that option (and it is an option)? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 11:27:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA02752 for hackers-outgoing; Tue, 17 Oct 1995 11:27:47 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA02745 for ; Tue, 17 Oct 1995 11:27:43 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA27951; Tue, 17 Oct 1995 11:21:46 -0700 From: Terry Lambert Message-Id: <199510171821.LAA27951@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 17 Oct 1995 11:21:46 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199510162245.XAA27289@uriah.heep.sax.de> from "J Wunsch" at Oct 16, 95 11:45:15 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3497 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > The problem with KOI-8 is that KOI-8 is a defacto standard, and is not > > accepted by international standards bodies. Mostly because the most > > popular BBS software in the area picked it up instead of 8859-9. > > The X Consortium finally agreed to accept koi8-r as a valid character > set/encoding. > > :-) 8-(. > Well, if we would rely on things like ISO, we wouldn't use IP etc. > and suffer from OSI/X.400 instead... Or X.500. Wait, that would be a good thing. I agree that FTAM and all that cruft really, really sucks. I'm only pointing at ISO so that you Western Europeans (8-)) don't have to live with a C locale that doesn't include high bits (collation, etc. is your own problem -- fix the code if you want it). > > The problem is not in the blank areas of the locale. > > > > In point of fact, the ANSI standards for terminal control sequences > > after ANSI 3.64 leave the codes in columns 0x80 and 0x90 to be used > > to represent 8 bit command sequence introducers, which are the same > > as an escape character followed by a character in columns 0x20 or 0x30. > > Because of this, KOI-8 as a character set is not compatible with post > > 3.64 ANSI terminal control sequence standardization. > > Do you know KOI8-R? It doesn't even touch those areas. This is NOT > IBM's code page crime. KOI8-R does basically use the same printable > characters like ISO-8859-*. The most notable difference to the > ISO-8859-* fonts is that KOI has the upper/lower case reversed for > some obscure reason. According to the Taligent published translation tables (yes, I know, they swear they don't own them) for KOI8<->Unicode round trip conversion, those code points are allocated but optional. I really think you are looking at a font that doesn't implement all the code points in the character set. > > Really, they should be using the 8859 character set instead of KOI-8, > > but there is understood to be a large historical investment in the > > non-standard KOI-8 representation (unfortunately). > > You're sounding like the OSI protagonists when they started the German > educational network project (WiN) here. :-) I'm unfamiliar with the project, but if we sound alike, then they are probably right. 8-). Just kidding; OSI protocols rot. The "historical investment issue" with ISO 2022 and JIS-208/JIS-208,212 is the reason for the Japanese opposition to Unicode. Well, that and the use of Chinese dictionary sort order for the ideogrammatic characters in the CJK unification part of the standard, and the fact that you can't mask out all non-Japanese characters using a bit test. 8-). The question is whether a "round trip" translation can be done transparently, and the storage encoding varied for new systems with little impact. I think the answer is "yes". I'd be happy to ditch ASCII ordering for this as well, if it were necessary. ASCII happens to have columnar seperation for case conversion that is probably wrong, actually, and the "(", "[", "{", "<", and "`" characters ought to have their corresponding pairings a shift width apart. Maybe "\" and "/" and "-" and "+" should as well. Though this might play hell with bit test based command sequence recognition for 3.64 terminals. The point is that no one has proposed a better standard to which ASCII isn't already conformant, for better or for worse. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 11:29:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA02820 for hackers-outgoing; Tue, 17 Oct 1995 11:29:49 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA02813 for ; Tue, 17 Oct 1995 11:29:40 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA27961; Tue, 17 Oct 1995 11:23:34 -0700 From: Terry Lambert Message-Id: <199510171823.LAA27961@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 17 Oct 1995 11:23:34 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199510170711.IAA29408@uriah.heep.sax.de> from "J Wunsch" at Oct 17, 95 08:11:31 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 491 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Terry, keep in mind that English ain't Andrey's native language. His > "new person" was very apparently related to "new in this discussion > right now". > > Moshno vy govoritye po-russkij? Ya dumayu che Andrey govorit eto > yazyk luchshe. :-) > > (Sorry, my keyboard is not yet ready for KOI8-R input. :-) Neither is mine. But I'm not "Glupee". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 11:35:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA02950 for hackers-outgoing; Tue, 17 Oct 1995 11:35:22 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA02944 for ; Tue, 17 Oct 1995 11:35:17 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA27981; Tue, 17 Oct 1995 11:29:24 -0700 From: Terry Lambert Message-Id: <199510171829.LAA27981@phaeton.artisoft.com> Subject: Re: Creating a /dev/random To: bde@zeta.org.au (Bruce Evans) Date: Tue, 17 Oct 1995 11:29:24 -0700 (MST) Cc: bde@zeta.org.au, jdl@chrome.onramp.net, hackers@FreeBSD.ORG, mark@grondar.za In-Reply-To: <199510170633.QAA29789@godzilla.zeta.org.au> from "Bruce Evans" at Oct 17, 95 04:33:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 765 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > >> Oops, I misread `one process'. Well, one process can't be in the kernel > >> twice. > > >...until SMP is implemented and then the whole locking issue > >comes into play, right? > > No. Until async i/o is implemented, perhaps. Or a threaded C library is defined, such that all system calls that "might take a long time" (ie: do not come from immediate data) may be turned into a call through an alternate trap gate (making them "async") plus a user or kernel space user thread context switch. Or the vnode locking is relaxed, allowing multiple entrancy into much of the file system during long delay I/O operations. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 11:37:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA03028 for hackers-outgoing; Tue, 17 Oct 1995 11:37:45 -0700 Received: from io.org (root@io.org [142.77.70.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA03020 for ; Tue, 17 Oct 1995 11:37:41 -0700 Received: from flinch.io.org (flinch.io.org [198.133.36.153]) by io.org (8.6.12/8.6.12) with SMTP id OAA29330 for ; Tue, 17 Oct 1995 14:35:49 -0400 Date: Tue, 17 Oct 1995 14:35:57 -0400 (EDT) From: Brian Tao To: FREEBSD-HACKERS-L Subject: Machine lockup, IRC and FTP server Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk I'm starting to see total machine lockup on my IRC/FTP server (2.1.0-950928-STABLE, 486DX2/66, irc 2.8.21, wu-ftpd 2.4). The only pattern I can deduce so far is that it happens after about 2 days of uptime. During those two days, the machine runs beautifully. With 64 megs, it hardly touches swap even with a fully loaded EFnet IRC server and 50-100 FTP connections. Then, out of the blue, it just freezes up (always when I'm away from the office too :-/). I built a new kernel with NMBCLUSTERS=1024, but that didn't seem to help much. No warnings about running out of mbufs are sent to syslog. In fact, nothing at all in syslog would indicate something went wrong. The machine just locks up, no console switching, no network, no kernel panic, nothing. I've monitored the output from top, pstat -T, pstat -s, netstat -m and netstat 1. The only abnormality is the high number of collisions on our Ethernet (15% to 75%, but that's another story). I don't see any wild fluctuation in the numbers that would cause the machine to hang like this. Any idea what I can do to tweak the kernel, or other stats I should be monitoring? Is there a way to find out the NMBCLUSTERS for a given kernel (assuming the kernel config is no longer available)? -- Brian Tao System Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Tue Oct 17 11:43:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA03158 for hackers-outgoing; Tue, 17 Oct 1995 11:43:04 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA03153 for ; Tue, 17 Oct 1995 11:43:01 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA28008; Tue, 17 Oct 1995 11:37:44 -0700 From: Terry Lambert Message-Id: <199510171837.LAA28008@phaeton.artisoft.com> Subject: Re: netisr code.. To: bde@zeta.org.au (Bruce Evans) Date: Tue, 17 Oct 1995 11:37:43 -0700 (MST) Cc: hackers@FreeBSD.ORG, julian@ref.tfs.com In-Reply-To: <199510170755.RAA00245@godzilla.zeta.org.au> from "Bruce Evans" at Oct 17, 95 05:55:47 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1113 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > That is slower at the end. However, micro-optimizations here are probably > not important. Everything except the atomic btrl could be written in C > and you probably wouldn't notice the difference. I would. ;-). I guess I'm just a computational nanosecond kinda guy. Comes from growing up on 1KHz machines with 8k or less of memory, I suppose, instead of on VAXen "where instructions are emulated and memory is free". The attitute that an optimization "doesn't matter" (this one is a bad example -- it's not really an optimization) is bad. That said, there is plenty of "low hanging fruit" that should be picked before going into instruction counting mode (unless you are doing kernel function block profiling -- if you are, then you have arrows pointing to where you need to fix the code). Now to totally confuse things: I think there should be C versions of all possible assembly code to aid porting. Anything that works is better than anything that doesn't. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 11:54:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA03469 for hackers-outgoing; Tue, 17 Oct 1995 11:54:20 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA03464 for ; Tue, 17 Oct 1995 11:54:15 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id TAA09185 for ; Tue, 17 Oct 1995 19:54:02 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id TAA02367 for freebsd-hackers@FreeBSD.ORG; Tue, 17 Oct 1995 19:54:01 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id TAA01782 for freebsd-hackers@FreeBSD.ORG; Tue, 17 Oct 1995 19:48:42 +0100 (MET) From: Ollivier Robert Message-Id: <199510171848.TAA01782@keltia.freenix.fr> Subject: Libc To: freebsd-hackers@FreeBSD.ORG (FreeBSD Hackers' list) Date: Tue, 17 Oct 1995 19:48:41 +0100 (MET) X-Operating-System: FreeBSD 2.2-CURRENT ctm#1215 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Hello, I know I can build a libc without YP but then "make world" will fail while trying to make ypserv and friends... Could it be possible to define NOYP=yes (for instance) before "make world" and get YP-free binaries ? That would lighten /bin and /sbin binaries a bit... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #0: Sat Oct 14 19:05:10 MET 1995 From owner-freebsd-hackers Tue Oct 17 12:00:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA03751 for hackers-outgoing; Tue, 17 Oct 1995 12:00:33 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA03746 for ; Tue, 17 Oct 1995 12:00:31 -0700 Received: from exalt.x.org by expo.x.org id AA10076; Tue, 17 Oct 95 14:59:59 -0400 Received: from localhost by exalt.x.org id OAA19177; Tue, 17 Oct 1995 14:59:57 -0400 Message-Id: <199510171859.OAA19177@exalt.x.org> To: ache@astral.msk.su Cc: hackers@freefall.FreeBSD.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Tue, 17 Oct 1995 20:29:46 EST. Organization: X Consortium Date: Tue, 17 Oct 1995 14:59:56 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > In message <199510171353.JAA08843@exalt.x.org> Kaleb S. KEITHLEY > writes: > > > >> In message <199510170809.SAA07948@rf900.physics.usyd.edu.au> David > >> Dawes writes: > >> > >> >If they ship Cyrillic fonts with their next release, they've indicated > >> >(to me at least) that their preference is to use the ISO8859-5 encoding. > >> > >> Sigh. Why they not asking what preferences russsians have? > > >Because the X Consortium is a Standards Body. When there is an existing > >standard for something we prefer to follow it (Like RFC 821/822). In the > >face of a "real" standard, a de facto standard doesn't count. > > What do you mean by "real"? KOI8-R has two references now, they are > RFC 1489 (description) and RFC 1700 (registration as valid MIME > charset name). Is it enough for "real"? If you mean only ISO by "real", > why you refer RFC 822? > As far as SMTP is concerned I'm not aware that any of the standards bodies have a standard for that; therefore RFC 822 is the best thing available. When Terry refered to KOI8-R as a de facto standard you said nothing to indicate that that was an unfair or inaccurate characterization; therefore I presumed that Terry was correct in calling it a de facto standard. The fact that KOI8-R has been codified in an RFC notwithstanding, there is an ISO standard (irrespective of how useful most Russians think it is), and an ISO Standard carries a lot more weight than an RFC; therefore the X Consortium would still prefer to ship ISO8859-5 over KOI8-R in the Sample Implementation. Note that the X Consortium doesn't ship a lot of fonts for the various encodings that our members do support, e.g.: Hewlett Packard "roman8" and "HP-JAPANESEEUC" encoded fonts, "ibm-special" and "adobe- fontspecific" to name just a few. Those are left for vendors, VARs and other third parties like XFree86 to handle in their products. -- Kaleb KEITHLEY X Consortium From owner-freebsd-hackers Tue Oct 17 12:07:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA03951 for hackers-outgoing; Tue, 17 Oct 1995 12:07:46 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA03944 for ; Tue, 17 Oct 1995 12:07:40 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id UAA09393 for ; Tue, 17 Oct 1995 20:07:36 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id UAA02430 for freebsd-hackers@FreeBSD.ORG; Tue, 17 Oct 1995 20:07:36 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id UAA01970 for freebsd-hackers@FreeBSD.ORG; Tue, 17 Oct 1995 20:05:02 +0100 (MET) From: Ollivier Robert Message-Id: <199510171905.UAA01970@keltia.freenix.fr> Subject: crt0.c To: freebsd-hackers@FreeBSD.ORG (FreeBSD Hackers' list) Date: Tue, 17 Oct 1995 20:05:02 +0100 (MET) X-Operating-System: FreeBSD 2.2-CURRENT ctm#1215 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG Precedence: bulk With all the talk about crt0.c, locale and friends, I just saw the following : crt0.c: if (getenv("ENABLE_STARTUP_LOCALE") != NULL) _startup_setlocale(LC_ALL, ""); asm ("__callmain:"); /* Defined for the benefit of debuggers */ exit(main(kfp->kargc, argv, environ)); } [...] static char * _getenv(name) register char *name; { extern char **environ; register int len; register char **P, *C; Why is it using "regular" getenv when it already has its own private one _getenv ? Note that changing getenv to _getenv does not really reduce binary size. I've tried to recompile crt0.c without any *STARTUP* variables defined to remove Andrey's "hack" and link "ls" static with it but "ls" doesn't change. -r-xr-xr-x 1 bin bin 167936 Oct 8 09:02 /bin/ls* -rwxr-xr-x 1 root wheel 167936 Oct 17 20:03 /usr/src/bin/ls/obj/ls* That's probably expected, maybe I did not follow the proper procedure. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #0: Sat Oct 14 19:05:10 MET 1995 From owner-freebsd-hackers Tue Oct 17 12:09:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA04021 for hackers-outgoing; Tue, 17 Oct 1995 12:09:25 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA04002 for ; Tue, 17 Oct 1995 12:09:18 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id NAA07670; Tue, 17 Oct 1995 13:10:37 -0600 Date: Tue, 17 Oct 1995 13:10:37 -0600 From: Nate Williams Message-Id: <199510171910.NAA07670@rocky.sri.MT.net> To: Terry Lambert Cc: bde@zeta.org.au (Bruce Evans), hackers@FreeBSD.ORG Subject: Optimizations matter? ( was Re: netisr code..) In-Reply-To: <199510171837.LAA28008@phaeton.artisoft.com> References: <199510170755.RAA00245@godzilla.zeta.org.au> <199510171837.LAA28008@phaeton.artisoft.com> Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Terry Lambert writes: > > That is slower at the end. However, micro-optimizations here are probably > > not important. Everything except the atomic btrl could be written in C > > and you probably wouldn't notice the difference. > > The attitute that an optimization "doesn't matter" (this one is a bad > example -- it's not really an optimization) is bad. In theory I agree with you. However, in practice I've found that most micro-optimizations make the code *MUCH* (!!!!!) more un-readable, and thus the optimization isn't worth the loss of maintainability. Again, this is a hard call to make, but needs to be mentioned. But, given 'optimized' versions and corresponding 'C' versions of the code is a nice tradeoff. That way a person can (hopefully) see what the code is attempting to do in a more readable manner while still having access to highly optimized implementations as well. Nate From owner-freebsd-hackers Tue Oct 17 12:11:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA04080 for hackers-outgoing; Tue, 17 Oct 1995 12:11:07 -0700 Received: from nanolon.gun.de (nanolon.gun.de [192.109.159.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA04075 for ; Tue, 17 Oct 1995 12:10:59 -0700 Received: (from uucp@localhost) by nanolon.gun.de (8.6.8.1/8.6.6) with UUCP id UAA20682 for hackers@freebsd.org; Tue, 17 Oct 1995 20:10:49 +0100 Received: from knobel.gun.de (localhost [127.0.0.1]) by knobel.gun.de (8.6.12/8.6.12) with SMTP id TAA04849 for ; Tue, 17 Oct 1995 19:19:24 +0100 Date: Tue, 17 Oct 1995 19:19:23 +0100 (MET) From: Andreas Klemm To: hackers@freebsd.org Subject: Re: can't compile GENERIC kernel because of undefined symbols In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sun, 15 Oct 1995, Andreas Klemm wrote: I supped /sys once again and removed -pipe from within /etc/make.conf: COPTFLAGS+=-pipe Now everything works fine. $$ apsfilter - magic print filter 4lpd @home : andreas@knobel.gun.de $$ ftp://sunsite.unc.edu @work : andreas@sunny.wup.de $$ /pub/Linux/system/Printing/aps-491.tgz knobel: >>> powered by FreeBSD <<< From owner-freebsd-hackers Tue Oct 17 12:28:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA04386 for hackers-outgoing; Tue, 17 Oct 1995 12:28:21 -0700 Received: from netcom23.netcom.com (root@netcom23.netcom.com [192.100.81.137]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA04379 ; Tue, 17 Oct 1995 12:28:18 -0700 Received: from localhost by netcom23.netcom.com (8.6.12/Netcom) id LAA28198; Tue, 17 Oct 1995 11:51:28 -0700 Message-Id: <199510171851.LAA28198@netcom23.netcom.com> To: Terry Lambert cc: bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? In-reply-to: Your message of "Tue, 17 Oct 95 10:55:49 PDT." <199510171755.KAA27890@phaeton.artisoft.com> Date: Tue, 17 Oct 95 11:51:24 -0700 From: Bakul Shah Sender: owner-hackers@FreeBSD.org Precedence: bulk > I assume (well, you assume 8-)) the size of the bit vector array type > in the declaration is sizeof(x) == NFDBITS? No. NFDBITS == sizeof (fd_mask) * 8. Type fd_mask is defined to be long. As far as the kernel is concerned, select() args that are bit vector arrays, are *large* enough to hold nfds number of descriptors, where nfds is the first arg to select(). The (uap->nd <= p->p_fd->fd_nfiles) check bounds this number to something sensible. > I don't see where this massive amount of runtime work is really worth it. It is not massive amount of runtime work. Changes are fairly straight forward. The runtime cost is small. It is worth it to me. But a more general argument is that without this fix file descriptors > FD_SETSIZE are second class citizens. You _are_ a fan of consistency, are you?:-) > /usr/unclude/sys/types.h has the forllowing in it: > #ifndef FD_SETSIZE > #define FD_SETSIZE 256 > #endif This is well and good for *user* programs. Most programs don't want to bother with changing FD_SETSIZE and kernel changes I am proposing are transparent to such programs. > meaning you can option it higher in the kernel and you can #define it > higher before including . This is not a good option for commercial software. Customers generally don't like to rebuild the kernel for such things. So I am forced to use the more complex solution. It is difficult enough to convince companies to support {Net,Free}BSD -- unfortunately a lot more difficult than Linux (which is wildly more popular inspite of its growing pains) -- and this sort of scaling problems makes it harder -- especially when Solaris, IRIX etc. already do them right. > It should be an option. But like having C equivalents for asm library > routines or compiler inlines, it needs to be allowed to be turned off. > Most ports do not start out self hosting until quite some way down the > road, and the reason such things are avoided (or replicated) is to > ease porting requirements. Fair enough. So just do #define __inline__ /*inline*/ :-) --bakul From owner-freebsd-hackers Tue Oct 17 12:49:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA04923 for hackers-outgoing; Tue, 17 Oct 1995 12:49:07 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA04917 ; Tue, 17 Oct 1995 12:49:03 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA28127; Tue, 17 Oct 1995 12:43:37 -0700 From: Terry Lambert Message-Id: <199510171943.MAA28127@phaeton.artisoft.com> Subject: Re: Locale stuff: call for conclusion. To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Tue, 17 Oct 1995 12:43:37 -0700 (MST) Cc: core@FreeBSD.ORG, hackers@FreeBSD.ORG, phk@critter.tfs.com In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 17, 95 02:26:18 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1683 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > >B) execute 1. in the other sense of the word, and get crt0.s cleaned up. > > This will happen January 1st 1996 even if A) and/or C) hasn't happened. > > As you sayd > > as something more sane is implemented. > > I am completely against of removing this hack when nothing sane > implemented, so date doesn't play role here. I think it is a deadline on sane implementation. I also think a 6 month limit is the best you can impose, and Jan 1, though a nice deadline date, is probably too soon. > >C) execute 4, as soon as anybody volounteer to do it. > > Well, as we voting, here additional issue (D), if you care > of what sane can be implemented instead. By Terry idea we can > switch from XPG/4 to XPG/3, it allows as safely use setlocale() > in 8bit clean programs (not care of multibyte runic chars which > isn't really used by Terry words). I didn't quite say runic characters weren't used. I said that XPG/4's idea of runic characters wasn't used. It's not quite the same thing, since neither approach will really support, for instance, shift-JIS, without a lot of work. > Switching to XPG/3 allowing as to fix almost every 8bit clean program > by simple adding setlocale(LC_ALL, "") into main(). I think XPG/3 is the right short term approach. I'm still a bit fuzzy on XPG/3->XPG/4 transition, since I have yet to see a fully localized piece of code to let me factor out all the differences. Since there is no message catalog support, I'd have to say that much of the distinctions are irrelevant, at least for now. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 12:58:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA05106 for hackers-outgoing; Tue, 17 Oct 1995 12:58:14 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA05100 ; Tue, 17 Oct 1995 12:58:10 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id MAA13671; Tue, 17 Oct 1995 12:57:47 -0700 To: Bakul Shah cc: ports@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: Pending crisis in packages/All/... In-reply-to: Your message of "Tue, 17 Oct 1995 10:42:24 PDT." <199510171742.KAA17733@netcom23.netcom.com> Date: Tue, 17 Oct 1995 12:57:47 -0700 Message-ID: <13668.813959867@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > Have your tools auto-search starting from the specified dir. > Thus you have, for example, Uh. Maybe it's just me, but I don't see how this is any different than what we have now. Jordan From owner-freebsd-hackers Tue Oct 17 13:01:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA05299 for hackers-outgoing; Tue, 17 Oct 1995 13:01:56 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA05289 for ; Tue, 17 Oct 1995 13:01:45 -0700 Received: by sequent.kiae.su id AA08895 (5.65.kiae-2 ); Tue, 17 Oct 1995 23:57:06 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 23:57:05 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id WAA01847; Tue, 17 Oct 1995 22:55:09 +0300 To: "FreeBSD Hackers' list" , Ollivier Robert References: <199510171905.UAA01970@keltia.freenix.fr> In-Reply-To: <199510171905.UAA01970@keltia.freenix.fr>; from Ollivier Robert at Tue, 17 Oct 1995 20:05:02 +0100 (MET) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 22:55:08 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: crt0.c Lines: 21 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 859 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message <199510171905.UAA01970@keltia.freenix.fr> Ollivier Robert writes: >Why is it using "regular" getenv when it already has its own private one >_getenv ? >Note that changing getenv to _getenv does not really reduce binary >size. I've tried to recompile crt0.c without any *STARTUP* variables >defined to remove Andrey's "hack" and link "ls" static with it but "ls" >doesn't change. 1) setlocale already uses standard getenv() so it doesn't matter. 2) Don't expect big size change (if ever), ls already uses ctype by itself. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Tue Oct 17 13:10:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA05498 for hackers-outgoing; Tue, 17 Oct 1995 13:10:24 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA05490 ; Tue, 17 Oct 1995 13:10:08 -0700 Received: by sequent.kiae.su id AA14651 (5.65.kiae-2 ); Wed, 18 Oct 1995 00:08:47 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Wed, 18 Oct 95 00:08:47 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id XAA01906; Tue, 17 Oct 1995 23:07:57 +0300 To: Terry Lambert Cc: core@FreeBSD.ORG, hackers@FreeBSD.ORG, phk@critter.tfs.com References: <199510171943.MAA28127@phaeton.artisoft.com> In-Reply-To: <199510171943.MAA28127@phaeton.artisoft.com>; from Terry Lambert at Tue, 17 Oct 1995 12:43:37 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 23:07:56 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: Locale stuff: call for conclusion. Lines: 60 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2442 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message <199510171943.MAA28127@phaeton.artisoft.com> Terry Lambert writes: >> >B) execute 1. in the other sense of the word, and get crt0.s cleaned up. >> > This will happen January 1st 1996 even if A) and/or C) hasn't happened. >> >> As you sayd >> > as something more sane is implemented. >> >> I am completely against of removing this hack when nothing sane >> implemented, so date doesn't play role here. >I think it is a deadline on sane implementation. I also think a 6 month >limit is the best you can impose, and Jan 1, though a nice deadline date, >is probably too soon. I agree. >> >C) execute 4, as soon as anybody volounteer to do it. >> >> Well, as we voting, here additional issue (D), if you care >> of what sane can be implemented instead. By Terry idea we can >> switch from XPG/4 to XPG/3, it allows as safely use setlocale() >> in 8bit clean programs (not care of multibyte runic chars which >> isn't really used by Terry words). >I didn't quite say runic characters weren't used. I said that XPG/4's >idea of runic characters wasn't used. It's not quite the same thing, >since neither approach will really support, for instance, shift-JIS, >without a lot of work. >> Switching to XPG/3 allowing as to fix almost every 8bit clean program >> by simple adding setlocale(LC_ALL, "") into main(). >I think XPG/3 is the right short term approach. I'm still a bit >fuzzy on XPG/3->XPG/4 transition, since I have yet to see a fully >localized piece of code to let me factor out all the differences. I also not see XPG/4 localize code. >Since there is no message catalog support, I'd have to say that >much of the distinctions are irrelevant, at least for now. I plan to made XPG/3 library from our XPG/4 sources, and this work almost done indirectly when wrote my hack. I can ether 1) disable rune coding expect NONE in mklocale and tune setlocale to not load rune coding. It is very fast solution but unused runes code still bloats stati binaries. or 2) Ifdef all XPG4 code (by #ifdef XPG4 f.e.) additionly to 1). or 3) Remove all XPG4-related sources and left only XPG3-related files additionly to 1) -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Tue Oct 17 13:16:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA05735 for hackers-outgoing; Tue, 17 Oct 1995 13:16:21 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA05723 ; Tue, 17 Oct 1995 13:16:10 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA03876; Tue, 17 Oct 1995 16:15:40 -0400 Date: Tue, 17 Oct 1995 16:15:40 -0400 From: "Garrett A. Wollman" Message-Id: <9510172015.AA03876@halloran-eldar.lcs.mit.edu> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) Cc: Terry Lambert , core@FreeBSD.ORG, hackers@FreeBSD.ORG, phk@critter.tfs.com Subject: Re: Locale stuff: call for conclusion. In-Reply-To: References: <199510171943.MAA28127@phaeton.artisoft.com> Sender: owner-hackers@FreeBSD.ORG Precedence: bulk < said: > I can ether > 1) disable rune coding expect NONE in mklocale and tune setlocale > to not load rune coding. > It is very fast solution but unused runes code still bloats > stati binaries. > or 2) Ifdef all XPG4 code (by #ifdef XPG4 f.e.) additionly to 1). > or 3) Remove all XPG4-related sources and left only XPG3-related files > additionly to 1) I dislike all three of these. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-hackers Tue Oct 17 13:20:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA05934 for hackers-outgoing; Tue, 17 Oct 1995 13:20:02 -0700 Received: from netcom22.netcom.com (bakul@netcom22.netcom.com [192.100.81.136]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA05920 ; Tue, 17 Oct 1995 13:19:57 -0700 Received: from localhost by netcom22.netcom.com (8.6.12/Netcom) id NAA04392; Tue, 17 Oct 1995 13:18:37 -0700 Message-Id: <199510172018.NAA04392@netcom22.netcom.com> To: "Jordan K. Hubbard" cc: ports@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: Pending crisis in packages/All/... In-reply-to: Your message of "Tue, 17 Oct 95 12:57:47 PDT." <13668.813959867@time.cdrom.com> Date: Tue, 17 Oct 95 13:18:34 -0700 From: Bakul Shah Sender: owner-hackers@FreeBSD.org Precedence: bulk > Uh. Maybe it's just me, but I don't see how this is any > different than what we have now. Instead of All/, networking/, multimedia/ etc. you have All/ Multimedia/ Sound/ Video/ Networking/ www/ ipx/ Editors/ .... and so on. There are no symlinks. All package names are unique withing the All/ tree -- the dir. hierarchy is merely for logical grouping (for humans). I don't know how you plan to change pkg_add but if I were doing it, I would do something like this: PKG_PATH=/local-packages/All://ftp.freebsd.org/FreeBSD/packages/All/ Then pkg_add foo.tgz first looks for foo.tgz in /local-packages/All dir. and all of its subdirectoris and then ftp.freebsd.org/FreeBSD/packages/All and all of its subdirectory. As you can see, the All dir. is redundant :-) Too bad that : is used in both PATHs as well as URLs. --bakul From owner-freebsd-hackers Tue Oct 17 13:27:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA06525 for hackers-outgoing; Tue, 17 Oct 1995 13:27:30 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA06514 for ; Tue, 17 Oct 1995 13:27:25 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA28228; Tue, 17 Oct 1995 13:21:57 -0700 From: Terry Lambert Message-Id: <199510172021.NAA28228@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Tue, 17 Oct 1995 13:21:57 -0700 (MST) Cc: kaleb@x.org, hackers@freefall.freebsd.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 17, 95 08:29:46 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2909 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >> >If they ship Cyrillic fonts with their next release, they've indicated > >> >(to me at least) that their preference is to use the ISO8859-5 encoding. > >> > >> Sigh. Why they not asking what preferences russsians have? > > >Because the X Consortium is a Standards Body. When there is an existing > >standard for something we prefer to follow it (Like RFC 821/822). In the > >face of a "real" standard, a de facto standard doesn't count. > > What do you mean by "real"? KOI8-R has two references now, they are > RFC 1489 (description) and RFC 1700 (registration as valid MIME > charset name). Is it enough for "real"? If you mean only ISO by "real", > why you refer RFC 822? This is a transfer encoding format. This is very different than a character set standard. You will need to send a representative to your national standards body which is your countries ISO standards body representative member, and it will need to petition ISO for modification of 8859-1. Barring that, you will need to get you national standards body to codify KOI-8 as a regional standard. If this is "what Russians prefer", then they should, as a whole, tell us that that's what they prefer by codifying the standard. The fact that 8859-5 is codified and KOI-8 is not is a strong argument that 8859-5 is preferred in general, even if you in particular don't prefer it. If this isn't the actual case, then the way to notify us of your preference change is to codify it, either as a regional standard, so that it can be a "supported for commnications in the locale", or preferrably as a change to the formal ISO standard, so that it can be "an extra-nationally recognized character set". As things stand, the only extra-nationally recognized standard for Cyrillic is 8859-5, period. The only real issue here is that formal internationalization is required for programs to use informal standards. KOI-8 would not be a formally acceptable ISO 8859-x standard because of the 8859-x layout rules violations it engages in -- the same reason it would not benefit equally with 8859-1..8 for a 8859-1 C locale. Formal internationalization is also required even in a 8859-1 locale for collation sequence, etc., so the discrepancies between 8859-1 and 8859-5 are larely irrelevant compared to the discrepancies between 8859-1 (or 5) and KOI-8. You can have your preferred standard, and your preferred encoding, but you will have to pay for it in code localization effort. The question you have to answer is "how do I want to pay?". With the 8859-5 encoding, you pay in conversion of legacy data. With KOI-8, you pay in code localization. It's your choice, but you will pay, one way or another, for historical use of KOI-8. It's just a matter of "how" and "when". Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 13:39:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA06813 for hackers-outgoing; Tue, 17 Oct 1995 13:39:42 -0700 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA06805 for ; Tue, 17 Oct 1995 13:39:34 -0700 Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from mail.hanse.de (134.100.239.2) with smtp id ; Tue, 17 Oct 95 21:38 MET Received: from wavehh.UUCP by mail.hanse.de with UUCP for gillham@andrews.EDU id ; Tue, 17 Oct 95 21:14 MET Received: by wavehh.hanse.de (4.1/SMI-4.1) id AA15624; Tue, 17 Oct 95 18:53:16 +0100 Date: Tue, 17 Oct 95 18:53:16 +0100 From: cracauer@wavehh.hanse.de (Martin Cracauer) Message-Id: <9510171753.AA15624@wavehh.hanse.de> To: gillham@andrews.EDU Cc: FreeBSD-Hackers@freebsd.org Subject: Re: Stability questions... Newsgroups: hanse-ml.freebsd.hackers References: <9510171512.AA24607@edmund> Reply-To: cracauer@wavehh.hanse.de Sender: owner-hackers@freebsd.org Precedence: bulk gillham@andrews.EDU (Andrew Gillham) wrote: >Apologies if this is the wrong mailing list. >I installed FreeBSD 2.0.5-RELEASE over the weekend, and I have >been having problems with it. What I am seeing is "cc1 interrupted >by signal 11" or similar when I am trying to compile a kernel. >Restarting make will eventually get it all built though. Is this a >known problem with 2.0.5-RELEASE, or is my hardware flakey? I can reliable make by box behave that way by either playing with the RAM timing settings or by overclocking the CPU. So I'm sure it is a hardware problem. >I have been running NetBSD on this box without any problems. That is odd, yes. When I kick my Mainboard, both NetBSD and FreeBSD break. Maybe it's a possible explanation that NetBSD uses other memory banks to provide memory for the compiler by default. You have 32 MB and only about 8 are used in compilations. And I know that the AMD chips have some littel differences in the MMU hardware. Maybe the FreeBSD VM system does something else here than NetBSD. Try that: - Remove some of your RAM, try different SIMMs on their own. - Turn of external Cache (standard answer :-) - Maybe you can try an Intel CPU? - Try a different SCSI controller. Yes, sounds odd, but the FreeBSD VM/buffer-cache system can provide files much faster that NetBSD does. NetBSD has one extra level of copying in RAM. Maybe this shows up timing problems with your system. Try for example a 1542, which will make things slower. OK, it really sounds odd. And let us know what solves the problem! >Also, I supped freebsd-current onto my NetBSD NFS server, and tried >building it. I was able to build a kernel and /sbin/* (by restarting >make whenever cc1 got a SEGV), and rebooted with the new kernel. This >new kernel didn't appear to have the SEGV problem, but I'm not 100% >sure, as something else broke. After a few minutes of compiling (on the >NFS mount) the kernel says "Biodone: buffer already done" or something >and hangs my compile. (sorry for the not exact errors, but I'm at >work, and the PCs are at home) Accessing the NFS mountpoint will hang >my shell, but I can still halt the box from another console. >Any ideas? Should I be trying to update to 2.1-current instead of >2.2-current? (how would I do that? I just ask for 'current' via sup.) Absolutely. 2-2-current is lilely to have problems. It is not like NetBSD-current, it is much more "experimental". The 2-1 snapshots are the best solution for production systems that should be up-to-date, but stable. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer - Fax +49 40 522 85 36 BSD User Group Hamburg, Germany - No NeXTMail anymore, please. Copyright 1995. Redistribution via Microsoft Network is prohibited From owner-freebsd-hackers Tue Oct 17 13:41:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA06877 for hackers-outgoing; Tue, 17 Oct 1995 13:41:18 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA06869 ; Tue, 17 Oct 1995 13:41:09 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA28258; Tue, 17 Oct 1995 13:35:27 -0700 From: Terry Lambert Message-Id: <199510172035.NAA28258@phaeton.artisoft.com> Subject: Re: Locale stuff: call for conclusion. To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Tue, 17 Oct 1995 13:35:27 -0700 (MST) Cc: terry@lambert.org, core@FreeBSD.ORG, hackers@FreeBSD.ORG, phk@critter.tfs.com In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 17, 95 11:07:56 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2714 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > >I think XPG/3 is the right short term approach. I'm still a bit > >fuzzy on XPG/3->XPG/4 transition, since I have yet to see a fully > >localized piece of code to let me factor out all the differences. > > I also not see XPG/4 localize code. I mean that I have seen (done) both XPG/3 and XPG/4 localization, I've just not seen a full catalog, etc, localization using both approaches on otherwise identical code. I have some friends at Unisys that have dealt with localization of legacy code, converting from XPG/3 to XPG/4. I'd just have to hit them up for examples, which would take a lot of my and their time. So I can't diff them and see a clear XPG/3->XPG/4 migration path with only partial jobs (ie: no message catalogs or whatever). > I plan to made XPG/3 library from our XPG/4 sources, and this work > almost done indirectly when wrote my hack. > > I can ether > 1) disable rune coding expect NONE in mklocale and tune setlocale > to not load rune coding. I'd prefer a default disabling of runic encoding usage. I expect that eventually this would later go away as the code is updated, so it becomes a code migration issue. > It is very fast solution but unused runes code still bloats > stati binaries. As long as it is transitional code with a deadline for removal, it's fine to include it. Maybe even use a preprocessor test to start spitting messages in transitional code if compiled after some date. (I know: it's evil). > or 2) Ifdef all XPG4 code (by #ifdef XPG4 f.e.) additionly to 1). > or 3) Remove all XPG4-related sources and left only XPG3-related files > additionly to 1) Better to #ifdef. I assume that one day we will want to support XPG/4, and it would be better to not have to recreate the code from scratch to do so. It also gives a quick testbed that will let us understand the code migration issues. Typically, I'd like a library to be linked before libc that let me have XPG/4 instead of XPG/3 so I could migrate the now XPG/3 code to XPG/4 awareness without having to do it all at once. That also means a function reference kludge for symbol preresoloution using XPG/4 symbol definitions before the symbols are required by the rest of the libc code. Probably a required dead code stub that lives in the same object module as setlocale() and pulls in everything else, which can also be removed when/if XPG/4 replaces XPG/3 in libc. I get a bit wary when you have to start playing linker tricks, but in this case, it seems the best approach for getting a code transitioning platform up and running with the least effort. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 13:44:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA07096 for hackers-outgoing; Tue, 17 Oct 1995 13:44:35 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA07086 ; Tue, 17 Oct 1995 13:44:23 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA28274; Tue, 17 Oct 1995 13:38:16 -0700 From: Terry Lambert Message-Id: <199510172038.NAA28274@phaeton.artisoft.com> Subject: Re: Locale stuff: call for conclusion. To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Tue, 17 Oct 1995 13:38:16 -0700 (MST) Cc: ache@astral.msk.su, terry@lambert.org, core@FreeBSD.ORG, hackers@FreeBSD.ORG, phk@critter.tfs.com In-Reply-To: <9510172015.AA03876@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 17, 95 04:15:40 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 808 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > 1) disable rune coding expect NONE in mklocale and tune setlocale > > to not load rune coding. > > It is very fast solution but unused runes code still bloats > > stati binaries. > > or 2) Ifdef all XPG4 code (by #ifdef XPG4 f.e.) additionly to 1). > > or 3) Remove all XPG4-related sources and left only XPG3-related files > > additionly to 1) > > I dislike all three of these. Why do you dislike the #ifdef XPG4? It seems the sane soloution for code transitioning... the code can't all be transitioned to runic support at once, and runic support is less than useful at present in any case because of ISO 2022 and shift-JIS not quite fitting XPG/4 in any case. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 13:48:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA07231 for hackers-outgoing; Tue, 17 Oct 1995 13:48:26 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA07225 for ; Tue, 17 Oct 1995 13:48:13 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA28303; Tue, 17 Oct 1995 13:42:22 -0700 From: Terry Lambert Message-Id: <199510172042.NAA28303@phaeton.artisoft.com> Subject: Re: Very slot TCP connections? To: dawes@rf900.physics.usyd.edu.au (David Dawes) Date: Tue, 17 Oct 1995 13:42:22 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <199510171436.AAA09365@rf900.physics.usyd.edu.au> from "David Dawes" at Oct 18, 95 00:36:03 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1158 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > I've recently noticed a problem when attempting to transfer data via > ftp from a site (ftp.usyd.edu.au, which is running Solaris 2.3 or 2.4, > and using wuftpd 2.4). My FreeBSD 2.0.5 machine is connected to the > net via the user-mode ppp dialup to an Annex terminal server. The ftp > site I'm connecting to is local to the Annex side. The problem is that > transfers are painfully slow -- a directory listing comes through at > about one line every 30 seconds. I haven't noticed this problem when > using ftp to other machines, and I don't see the problem if I connect > from a machine local to that ftp server (but I don't have any FreeBSD > 2.0.5 machines on that side). I've got tcp_extensions set to NO. > > I've also found http connections to that site to be unusably slow, although > if I go via a proxy at the remote end it is OK. > > Anyone have any ideas about this or about how I could go about tracing > what the problem is? In /etc/sysconfig, change: tcp_extensions=YES To: tcp_extensions=NO Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 14:12:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA08317 for hackers-outgoing; Tue, 17 Oct 1995 14:12:29 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA08307 ; Tue, 17 Oct 1995 14:12:23 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA04040; Tue, 17 Oct 1995 17:12:00 -0400 Date: Tue, 17 Oct 1995 17:12:00 -0400 From: "Garrett A. Wollman" Message-Id: <9510172112.AA04040@halloran-eldar.lcs.mit.edu> To: Terry Lambert Cc: wollman@lcs.mit.edu (Garrett A. Wollman), ache@astral.msk.su, core@FreeBSD.ORG, hackers@FreeBSD.ORG, phk@critter.tfs.com Subject: Re: Locale stuff: call for conclusion. In-Reply-To: <199510172038.NAA28274@phaeton.artisoft.com> References: <9510172015.AA03876@halloran-eldar.lcs.mit.edu> <199510172038.NAA28274@phaeton.artisoft.com> Sender: owner-hackers@FreeBSD.ORG Precedence: bulk < said: > Why do you dislike the #ifdef XPG4? > It seems the sane soloution for code transitioning... the code can't > all be transitioned to runic support at once, and runic support is > less than useful at present in any case because of ISO 2022 and > shift-JIS not quite fitting XPG/4 in any case. I think the most sensible thing to do is to simply say ``multibyte locales are not supported'' and leave the code in for someone who actually uses such locales to find any problems. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-hackers Tue Oct 17 14:26:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA08684 for hackers-outgoing; Tue, 17 Oct 1995 14:26:43 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA08674 ; Tue, 17 Oct 1995 14:26:33 -0700 Received: by sequent.kiae.su id AA11534 (5.65.kiae-2 ); Wed, 18 Oct 1995 01:25:19 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Wed, 18 Oct 95 01:25:18 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id AAA02326; Wed, 18 Oct 1995 00:24:26 +0300 To: Terry Lambert , "Garrett A. Wollman" Cc: core@FreeBSD.ORG, hackers@FreeBSD.ORG, phk@critter.tfs.com References: <9510172015.AA03876@halloran-eldar.lcs.mit.edu> <199510172038.NAA28274@phaeton.artisoft.com> <9510172112.AA04040@halloran-eldar.lcs.mit.edu> In-Reply-To: <9510172112.AA04040@halloran-eldar.lcs.mit.edu>; from "Garrett A. Wollman" at Tue, 17 Oct 1995 17:12:00 -0400 Message-Id: Organization: Olahm Ha-Yetzirah Date: Wed, 18 Oct 1995 00:24:26 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: Locale stuff: call for conclusion. Lines: 30 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1320 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message <9510172112.AA04040@halloran-eldar.lcs.mit.edu> Garrett A. Wollman writes: >< said: >> Why do you dislike the #ifdef XPG4? >> It seems the sane soloution for code transitioning... the code can't >> all be transitioned to runic support at once, and runic support is >> less than useful at present in any case because of ISO 2022 and >> shift-JIS not quite fitting XPG/4 in any case. >I think the most sensible thing to do is to simply say ``multibyte >locales are not supported'' and leave the code in for someone who >actually uses such locales to find any problems. It is equal to my 1) expect I plan to block loading runes locale at software level, if someone ever tries. As I say, each static binaries will bloats by unused runic code in this case, its about 24K. P.S. Personally I don't care of bloating, but it was one of the strongest arguments against my locale hack, so where is non-bloating community? (just wonder :-). -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Tue Oct 17 14:28:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA08846 for hackers-outgoing; Tue, 17 Oct 1995 14:28:48 -0700 Received: from seattle.polstra.com (seattle.polstra.com [198.211.214.4]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA08837 for ; Tue, 17 Oct 1995 14:28:42 -0700 Received: from phaeton.artisoft.com by seattle.polstra.com with smtp (Smail3.1.28.1 #5) id m0t5JYp-000079C; Tue, 17 Oct 95 14:28 PDT Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA28400; Tue, 17 Oct 1995 14:23:44 -0700 From: Terry Lambert Message-Id: <199510172123.OAA28400@phaeton.artisoft.com> Subject: Re: getdtablesize() broken? To: jdp@polstra.com (John Polstra) Date: Tue, 17 Oct 1995 14:23:44 -0700 (MST) Cc: freebsd-hackers@polstra.com In-Reply-To: from "John Polstra" at Oct 17, 95 09:34:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5732 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > > Man pages only say that if the host does not support millisecond > > > accuracy then the value is rounded up to the nearest legal value > > > available. > > > > 10ms is the argument resoloution. On Solaris, it's 10ms, while select() > > is till 4uS. select() wins. 8-). > > Why do you say "10ms is the argument resoloution"? The man pages > explicitly say that the timeout is specified in milliseconds. Simple > tests indicate that the man pages are accurate. What is the basis for > your claim? The SVR4.2 man pages. You are reading the Sun man pages. Stop it. 8-). 1ms is too low a resolution in any case. I have apps that need 200uS; Colorado Memory systems has one that needs ~100uS (or a buzz loop). Sun hardware supports in the neighborhood of 4uS. That includes the printf in the test program and console scrolling. You are suggesting that 250 times less resoloution is acceptable, or that 2500 times less resoloution is acceptable, in the 10ms case. BTW: If you have a SVR4 or Solaris source license, look at the implementation of poll(). It uses the non-HRT timer services, which for non-RT processes are limited to a system quantum resoloution on a 100Hz timer. 1S/100 = 10ms. The inability to support setitimer/getitimer resoloutions at the system clock frequency is the basis of my claim that UnixWare snd SVR4.x are not in fact SVID compliant. Solaris wasn't, but I reported it and they fixed it, as well as fixing the ABI select() resoloution for statically, and later dynamically linked programs that call select(). One fault that Sun does not have is ignoring bug reports about standards conformance. If you have Sun hardware on hand that runs Solaris, I suggest you use gettimeofday (a statistically maintained value good to 4uS on most hardware after the SPARCStation 1+) to check your poll resoloution. I'd suggest the same for SVR4, but the system clock update frequency on SVR4 renders the gettimeofday() limited to 10ms resoloution (this is in fact acceptable under SVID, it's just bloody useless for profiling unless all you do is statistical profiling -- ie: how fast can I hit my cache). > > > [Responding to a claim by Terry that poll doesn't support simple timed > > > waits not involving file descriptors] > > > > > > That hasn't been my experience. poll(0, NULL, 10000); waits 10 seconds > > > on SunOS, all SVR4-en I have here, HPUX, and AIX; however Digital Unix's > > > poll looses. In fact in SVR4 select(3) is implemented using poll(2). > > > > That's a bug in SVR4. SVR4 is broken and bogus in many, many ways. > > You're confusing me. First you say that poll is no good because it > doesn't support simple timed waits. Then somebody points out that you > were wrong, and poll does in fact support that. So then you say that > polls which work that way are broken. > > Poll is broken, because it fails to exhibit the broken behavior which you > originally claimed it had? Have I got this right? No, poll is no good because it doesn't support *sufficient resoloution* on simple timed waits. In this case, "sufficient" is defined as being "equal to setitimer/getitimer". For the BSD case, this means that the interface would have to be changed. In addition, the select(2) call in BSD reserves the right to modify the timeval structure to indicate the remaining time to allow the use of the timeout as an even outcall mechanism for logical multithreading. The poll(2) call does not show the time remaining on the time in the non-timeout case. Poll is broken on Mentat-derived streams sources for no FD's present in the argument list. I think early versions of Lachman streams (ie: SCO) also have this bug. I don't know if Lachman has corrected them (neither does the former Lachman employee in the next office). AIX no longer has this bug (as of 3.1? 3.2?) because we reported it to IBM when we were using that mechanism for SAP daemons in the NetWare for UNIX 4.x code. I personally corrected the problem on the VMS version of Mentat Streams, and either Linda Shelton or Alan Clark of Novell personally corrected the problem in the Ultrix version. Basically, all DEC OS's that support poll() use Mentat sources, and then some, so you can't write portable code that depends on that behaviour. > > SVR4 is broken and bogus in many, many ways. > > Of course SVR4 is broken. FreeBSD is broken. Linux is broken. VMS is > broken. They're all broken, in one way or another. That doesn't > automatically mean that their every feature is broken. I said "broken and bogus". FreeBSD isn't bogus. 8-). If you can't depend on the feature working, it's effectively "not there". You have to decide then whether you want working code or portable code, or if you can find a different soloution. > I've used both select and poll in many, many applications. They both got > the job done for me. Your applications have obviously used timer resoloutions of 10ms or greater, or you were unaware of them rounding your value to 0 and causing a non-blocking check (and eating all free system time, if this was something's main control loop). UnixWare actually rounds non-zero values up to 10ms, which is, in fact, a violation of the select(3) documenation (but not the poll(2) documentation). This type of problem is non-obvious. I'm not blaming you for missing the non-conformance problems: without kernel sources, they are almost impossible to track. But they do exist, and I will scream bloody murder any time someone says they don't, especially if they say that instead of fixing the things. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 14:42:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA09374 for hackers-outgoing; Tue, 17 Oct 1995 14:42:35 -0700 Received: (from asami@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA09362 ; Tue, 17 Oct 1995 14:42:28 -0700 Date: Tue, 17 Oct 1995 14:42:28 -0700 From: Satoshi Asami Message-Id: <199510172142.OAA09362@freefall.freebsd.org> To: jkh@time.cdrom.com, phk@critter.tfs.com Subject: Re: Pending crisis in packages/All/... Cc: hackers@freefall.FreeBSD.org, ports@freefall.FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk * Uh, sorry - I mis-explained things badly. * * It IS that way now. It's actually having all those *files* in one * directory that breaks mkisofs, not just a lot of symlinks. So, just to clarify, it's the sheer number of files in that directory that's the problem and it has nothing to do with symlinks? If so, we have an even larger headache, as distfiles/ has an even greater number of files.... :< I need to think about this, it may require a major surgery in bsd.port.mk and a complete rebuild of packages.... Satoshi From owner-freebsd-hackers Tue Oct 17 14:55:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA09969 for hackers-outgoing; Tue, 17 Oct 1995 14:55:43 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA09960 for ; Tue, 17 Oct 1995 14:55:38 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA28478; Tue, 17 Oct 1995 14:48:50 -0700 From: Terry Lambert Message-Id: <199510172148.OAA28478@phaeton.artisoft.com> Subject: Re: Optimizations matter? ( was Re: netisr code..) To: nate@rocky.sri.MT.net (Nate Williams) Date: Tue, 17 Oct 1995 14:48:50 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, hackers@FreeBSD.ORG In-Reply-To: <199510171910.NAA07670@rocky.sri.MT.net> from "Nate Williams" at Oct 17, 95 01:10:37 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 562 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > But, given 'optimized' versions and corresponding 'C' versions of the > code is a nice tradeoff. That way a person can (hopefully) see what the > code is attempting to do in a more readable manner while still having > access to highly optimized implementations as well. The trick being to keep both sets of code updated on interface changes. 8-(. One might require that interface changes be made to the C code first? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 15:04:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA10287 for hackers-outgoing; Tue, 17 Oct 1995 15:04:26 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA10258 ; Tue, 17 Oct 1995 15:04:13 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA28514; Tue, 17 Oct 1995 14:58:27 -0700 From: Terry Lambert Message-Id: <199510172158.OAA28514@phaeton.artisoft.com> Subject: Re: Locale stuff: call for conclusion. To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Tue, 17 Oct 1995 14:58:27 -0700 (MST) Cc: terry@lambert.org, wollman@lcs.mit.edu, ache@astral.msk.su, core@FreeBSD.ORG, hackers@FreeBSD.ORG, phk@critter.tfs.com In-Reply-To: <9510172112.AA04040@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 17, 95 05:12:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 914 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > Why do you dislike the #ifdef XPG4? > > > It seems the sane soloution for code transitioning... the code can't > > all be transitioned to runic support at once, and runic support is > > less than useful at present in any case because of ISO 2022 and > > shift-JIS not quite fitting XPG/4 in any case. > > I think the most sensible thing to do is to simply say ``multibyte > locales are not supported'' and leave the code in for someone who > actually uses such locales to find any problems. This is workable, but it is less friendly for the transition from 8bit clean to rune-capable code. If I'm running a runic environment, this will cause transitioned 8bit clean code to fail. Wouldn't it be better to allow it to be tackled in two stages instead of all at once? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 15:05:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA10431 for hackers-outgoing; Tue, 17 Oct 1995 15:05:39 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA10410 for ; Tue, 17 Oct 1995 15:05:23 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA02508 for ; Tue, 17 Oct 1995 23:05:12 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id XAA05028 for freebsd-hackers@freebsd.org; Tue, 17 Oct 1995 23:05:11 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id XAA03328 for freebsd-hackers@freebsd.org; Tue, 17 Oct 1995 23:03:18 +0100 From: J Wunsch Message-Id: <199510172203.XAA03328@uriah.heep.sax.de> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Tue, 17 Oct 1995 23:03:18 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510171859.OAA19177@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 17, 95 02:59:56 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 518 Sender: owner-hackers@freebsd.org Precedence: bulk As Kaleb S. KEITHLEY wrote: > > The fact that KOI8-R has been codified in an RFC notwithstanding, there > is an ISO standard (irrespective of how useful most Russians think it > is), and an ISO Standard carries a lot more weight than an RFC; therefore ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So why do we still use TCP/IP? :-] -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Tue Oct 17 15:05:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA10453 for hackers-outgoing; Tue, 17 Oct 1995 15:05:44 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA10420 ; Tue, 17 Oct 1995 15:05:31 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA28529; Tue, 17 Oct 1995 15:00:00 -0700 From: Terry Lambert Message-Id: <199510172200.PAA28529@phaeton.artisoft.com> Subject: Re: Locale stuff: call for conclusion. To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Tue, 17 Oct 1995 14:59:59 -0700 (MST) Cc: terry@lambert.org, wollman@lcs.mit.edu, core@FreeBSD.ORG, hackers@FreeBSD.ORG, phk@critter.tfs.com In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 18, 95 00:24:26 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 415 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > P.S. Personally I don't care of bloating, but it was one of the > strongest arguments against my locale hack, so where is > non-bloating community? (just wonder :-). Putting an April 17th deadline on the conversion before the #define XPG4 goes in, of course... six months. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 15:19:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA10981 for hackers-outgoing; Tue, 17 Oct 1995 15:19:49 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA10962 for ; Tue, 17 Oct 1995 15:19:40 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA02851; Tue, 17 Oct 1995 23:19:27 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id XAA05134; Tue, 17 Oct 1995 23:19:27 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id XAA03659; Tue, 17 Oct 1995 23:17:35 +0100 From: J Wunsch Message-Id: <199510172217.XAA03659@uriah.heep.sax.de> Subject: Re: Very slot TCP connections? To: terry@lambert.org (Terry Lambert) Date: Tue, 17 Oct 1995 23:17:34 +0100 (MET) Cc: dawes@rf900.physics.usyd.edu.au, hackers@FreeBSD.ORG Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510172042.NAA28303@phaeton.artisoft.com> from "Terry Lambert" at Oct 17, 95 01:42:22 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 421 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk As Terry Lambert wrote: > > > 2.0.5 machines on that side). I've got tcp_extensions set to NO. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > In /etc/sysconfig, change: > > tcp_extensions=YES > > To: > > tcp_extensions=NO ???? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Tue Oct 17 15:23:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA11118 for hackers-outgoing; Tue, 17 Oct 1995 15:23:45 -0700 Received: from seattle.polstra.com (seattle.polstra.com [198.211.214.4]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA11112 for ; Tue, 17 Oct 1995 15:23:36 -0700 Received: by seattle.polstra.com (Smail3.1.28.1 #5) id m0t5KPw-000077C; Tue, 17 Oct 95 15:23 PDT Message-Id: Date: Tue, 17 Oct 95 15:23 PDT From: jdp@polstra.com (John Polstra) To: terry@lambert.org Cc: freebsd-hackers@freebsd.org Subject: Re: getdtablesize() broken? In-Reply-To: <199510172123.OAA28400@phaeton.artisoft.com> Sender: owner-hackers@freebsd.org Precedence: bulk > > > 10ms is the argument resoloution. On Solaris, it's 10ms, while select() > > > is till 4uS. select() wins. 8-). > > > > Why do you say "10ms is the argument resoloution"? The man pages > > explicitly say that the timeout is specified in milliseconds. Simple > > tests indicate that the man pages are accurate. What is the basis for > > your claim? > > The SVR4.2 man pages. You are reading the Sun man pages. Stop it. 8-). Even worse -- I was reading the SVR4.0 man pages. [Hangs head in shame.] But isn't the 10ms resolution just an artifact of a particular implementation? The timeout is still specified in milliseconds, isn't it? Surely they didn't change that!? (I'm genuinely asking, as I don't know the answer.) A poll implementation in FreeBSD could support a resolution of 1ms, that's my point. Given what you wrote next, I agree that this is moot anyway: > 1ms is too low a resolution in any case. I have apps that need 200uS; > Colorado Memory systems has one that needs ~100uS (or a buzz loop). OK, well, if people really need that kind of resolution then I can't argue with that. In that case you're certainly right that poll isn't up to the task. > > You're confusing me. First you say that poll is no good because it > > doesn't support simple timed waits. Then somebody points out that you > > were wrong, and poll does in fact support that. So then you say that > > polls which work that way are broken. > > > > Poll is broken, because it fails to exhibit the broken behavior which you > > originally claimed it had? Have I got this right? > > > No, poll is no good because it doesn't support *sufficient resoloution* > on simple timed waits. I completely misinterpreted your earlier remarks. Sorry. > In addition, the select(2) call in BSD reserves the right to modify the > timeval structure to indicate the remaining time to allow the use of > the timeout as an even outcall mechanism for logical multithreading. Yes. I wish more implementations of select actually did that. -- John John Polstra jdp@polstra.com Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Tue Oct 17 15:34:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA11682 for hackers-outgoing; Tue, 17 Oct 1995 15:34:01 -0700 Received: from pancake.remcomp.fr (root@pancake.remcomp.fr [194.51.30.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA11670 for ; Tue, 17 Oct 1995 15:33:47 -0700 Received: (from didier@localhost) by aida.org (8.6.12/8.6.9) id WAA00577; Mon, 16 Oct 1995 22:10:21 +0100 Date: Mon, 16 Oct 1995 22:10:20 +0100 (MET) From: Didier Derny To: HOSOKAWA Tatsumi cc: hackers@FreeBSD.ORG, hosokawa@mt.cs.keio.ac.jp Subject: Re: crash while running xanim In-Reply-To: <199510151923.EAA25631@frig.mt.cs.keio.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk On Mon, 16 Oct 1995, HOSOKAWA Tatsumi wrote: > In article > didier@aida.org writes: > > >> My computer crashed while I was playing a large .avi file (robroy.avi > >> from the Windows 95 cdrom). > >> I found these messages in /var/log/messages: > >> > >> swap_pager: out of space > >> process 302 killed by vm_fault -- out of swap. > > Use xanim with +f option. > > hosokawa > thanks but I dont know why the system crashed it should have killed xanim or X... I lost many files. -- Didier Derny didier@aida.org From owner-freebsd-hackers Tue Oct 17 15:42:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA11837 for hackers-outgoing; Tue, 17 Oct 1995 15:42:11 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA11832 ; Tue, 17 Oct 1995 15:42:05 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA28761; Tue, 17 Oct 1995 15:35:22 -0700 From: Terry Lambert Message-Id: <199510172235.PAA28761@phaeton.artisoft.com> Subject: Re: getdtablesize() broken? To: bakul@netcom.com (Bakul Shah) Date: Tue, 17 Oct 1995 15:35:22 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org In-Reply-To: <199510171851.LAA28198@netcom23.netcom.com> from "Bakul Shah" at Oct 17, 95 11:51:24 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2984 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > I don't see where this massive amount of runtime work is really worth it. > > It is not massive amount of runtime work. Changes are > fairly straight forward. The runtime cost is small. > > It is worth it to me. But a more general argument is that > without this fix file descriptors > FD_SETSIZE are second > class citizens. You _are_ a fan of consistency, are you?:-) Basically, all of the user space code that uses the standard-since-4.2 sys/types.h definitions would need to be rewritten. This is what I meant. > > /usr/unclude/sys/types.h has the forllowing in it: > > > #ifndef FD_SETSIZE > > #define FD_SETSIZE 256 > > #endif > > This is well and good for *user* programs. Most programs don't > want to bother with changing FD_SETSIZE and kernel changes > I am proposing are transparent to such programs. ??? How do I make a program which doesn't guard using FD_SETSIZE the max fd it tries to select upon suddenly have a larger statically or stack declared bitvector array? I can't. Programs that "don't bother" will get the FD_SETSIZE limit or get an error from the kernel, or more likely, corrupt whatever data lives right after where the fd_set lives and eventually mysteriously fail. Checking the limit isn't optional. Reacting to a discrepancy between the user and kernel limits (ie: handling error returns from select) is also not optional. Setting the limit: that's optionalm both in the kernel and in user space. > > meaning you can option it higher in the kernel and you can #define it > > higher before including . > > This is not a good option for commercial software. > Customers generally don't like to rebuild the kernel for > such things. So I am forced to use the more complex > solution. I don't see how you prevent the kernel from twiddling user bits that follow the fd_set declaration area in the processes address space (or getting a SEGV if it's the last item in the data segment) as a result of shoving down a number that wasn't guarded based on the user's FD_SETSIZE. This seems to be a recipe for bizarre and undetectable data corruption. > It is difficult enough to convince companies to support > {Net,Free}BSD -- unfortunately a lot more difficult than > Linux (which is wildly more popular inspite of its growing > pains) -- and this sort of scaling problems makes it harder > -- especially when Solaris, IRIX etc. already do them right. If we change the macro names, that means source changes for the people doing the porting, and that won't go over well. The problem occurs in large service sites. And the problem is related to the kernel not knowing how big the user FD_SETSIZE is at select call time. I don't see that going away without an interface change. > Fair enough. So just do > #define __inline__ /*inline*/ > :-) #define __inline__ static ? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 15:45:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA11950 for hackers-outgoing; Tue, 17 Oct 1995 15:45:14 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA11944 for ; Tue, 17 Oct 1995 15:45:05 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA28803; Tue, 17 Oct 1995 15:38:41 -0700 From: Terry Lambert Message-Id: <199510172238.PAA28803@phaeton.artisoft.com> Subject: Re: Very slot TCP connections? To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 17 Oct 1995 15:38:41 -0700 (MST) Cc: terry@lambert.org, dawes@rf900.physics.usyd.edu.au, hackers@FreeBSD.ORG In-Reply-To: <199510172217.XAA03659@uriah.heep.sax.de> from "J Wunsch" at Oct 17, 95 11:17:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 497 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > > 2.0.5 machines on that side). I've got tcp_extensions set to NO. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > In /etc/sysconfig, change: > > > > tcp_extensions=YES > > > > To: > > > > tcp_extensions=NO > > ???? Oops. Nate noticed this too. Never mind. You should use the -current telnet/telnetd code instead. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 15:49:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA12090 for hackers-outgoing; Tue, 17 Oct 1995 15:49:50 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA12058 ; Tue, 17 Oct 1995 15:49:21 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id PAA24971; Tue, 17 Oct 1995 15:49:05 -0700 To: Satoshi Asami cc: phk@critter.tfs.com, hackers@freefall.freebsd.org, ports@freefall.freebsd.org Subject: Re: Pending crisis in packages/All/... In-reply-to: Your message of "Tue, 17 Oct 1995 14:42:28 PDT." <199510172142.OAA09362@freefall.freebsd.org> Date: Tue, 17 Oct 1995 15:49:05 -0700 Message-ID: <24969.813970145@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > I need to think about this, it may require a major surgery in bsd.port.mk > and a complete rebuild of packages.... I would not favor any such "solution" to the problem. Let's everyone sit back a bit and think about this some more before we propose anything really evil. Jordan From owner-freebsd-hackers Tue Oct 17 16:44:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA13815 for hackers-outgoing; Tue, 17 Oct 1995 16:44:50 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA13807 ; Tue, 17 Oct 1995 16:44:44 -0700 Received: by sequent.kiae.su id AA02085 (5.65.kiae-2 ); Wed, 18 Oct 1995 03:39:18 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Wed, 18 Oct 95 03:39:17 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id CAA04713; Wed, 18 Oct 1995 02:38:57 +0300 To: Terry Lambert Cc: core@FreeBSD.ORG, hackers@FreeBSD.ORG, phk@critter.tfs.com, wollman@lcs.mit.edu References: <199510172200.PAA28529@phaeton.artisoft.com> In-Reply-To: <199510172200.PAA28529@phaeton.artisoft.com>; from Terry Lambert at Tue, 17 Oct 1995 14:59:59 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Wed, 18 Oct 1995 02:38:56 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: Locale stuff: call for conclusion. Lines: 19 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 800 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message <199510172200.PAA28529@phaeton.artisoft.com> Terry Lambert writes: >> P.S. Personally I don't care of bloating, but it was one of the >> strongest arguments against my locale hack, so where is >> non-bloating community? (just wonder :-). >Putting an April 17th deadline on the conversion before the #define XPG4 >goes in, of course... six months. Well... What is our final decision about XPG4->XPG3 migration? Does your words about #define XPG4 means that Garrett agrees to #ifdef XPG4 ? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Tue Oct 17 16:55:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA14207 for hackers-outgoing; Tue, 17 Oct 1995 16:55:27 -0700 Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA14199 for ; Tue, 17 Oct 1995 16:55:25 -0700 Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA10271; Tue, 17 Oct 1995 16:46:52 -0700 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA16212; Tue, 17 Oct 1995 19:46:51 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id TAA08488; Tue, 17 Oct 1995 19:47:45 GMT Message-Id: <199510171947.TAA08488@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: Bruce Evans Cc: hackers@freebsd.org Subject: Re: IPX now available In-Reply-To: Your message of "Tue, 17 Oct 1995 14:00:00 +1000." <199510170400.OAA23474@godzilla.zeta.org.au> X-Mailer: exmh version 1.5omega 10/6/94 Date: Tue, 17 Oct 1995 19:47:44 +0000 From: Matt Thomas Sender: owner-hackers@freebsd.org Precedence: bulk In <199510170400.OAA23474@godzilla.zeta.org.au> , you wrote: > >It depends on when drivers will be probed but if we assume it's before > >the process initialization, then this begs for kernel threads. While > >highly desirable, I think kernel threads would be overkill if added > >just for this. Instead, use of timeout() and proper sync points would > >achieve the same capability at far less implementation cost. > > timeout() is no use if there is nothing to give up control to. Control will return back to the caller of probe (or attach or ...). probe could return a meaningful status like EINPROGRESS which would tell the caller that the probe in continuing. Eventually the driver (via timeout) will call probe_done() to say the probe finished. I use a similar technique in the DC21x4x driver when autoprobing for the DC21041's media type. I use the general purpose timer register to cause interrupts at periodic intervals to test for status. The best thing is that system continues while the driver continues to sense the media. > I think > some sort of threading is required, and I want something that has the > same interface for drivers that are probed early and ones that are > probed after the system is running normally. Desirable, yes. Required, no. > tsleep() is good enough > for the latter case and its interface is probably be good enough for > early use. tsleep() itself could do something like > `if (cold) next_mini_thread(); else normal_stuff();'. If one adds threads, then that implies locking has been added or guarunteeing that will by invoked kernel services will not cause a scheduling event. Let me say upfront that I would love to have kernel threads. But I'm wary that you are underestinating the amount of work needed to add them. Properly done kernel thread services are probably the most significant and useful addition that can be made to FreeBSD. Can you say SMP? Real pthread support? Better real time support by thread preemption? Matt Thomas Internet: matt@lkg.dec.com 3am Software Foundry WWW URL: Westford, MA Disclaimer: Digital disavows all knowledge of this message From owner-freebsd-hackers Tue Oct 17 17:29:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA15671 for hackers-outgoing; Tue, 17 Oct 1995 17:29:01 -0700 Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA15665 for ; Tue, 17 Oct 1995 17:28:51 -0700 Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id KAA10676; Wed, 18 Oct 1995 10:27:34 +1000 From: David Dawes Message-Id: <199510180027.KAA10676@rf900.physics.usyd.edu.au> Subject: Re: Very slot TCP connections? To: terry@lambert.org (Terry Lambert) Date: Wed, 18 Oct 1995 10:27:34 +1000 (EST) Cc: joerg_wunsch@uriah.heep.sax.de, terry@lambert.org, hackers@FreeBSD.ORG In-Reply-To: <199510172238.PAA28803@phaeton.artisoft.com> from "Terry Lambert" at Oct 17, 95 03:38:41 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 546 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >> > > 2.0.5 machines on that side). I've got tcp_extensions set to NO. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> > In /etc/sysconfig, change: >> > >> > tcp_extensions=YES >> > >> > To: >> > >> > tcp_extensions=NO >> >> ???? > >Oops. Nate noticed this too. > >Never mind. > >You should use the -current telnet/telnetd code instead. For ftp and http connections? That's where I'm noticing the problem. The thing is, it isn't a genral problem. I mainly see it when connecting to this one site. David From owner-freebsd-hackers Tue Oct 17 18:14:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA17443 for hackers-outgoing; Tue, 17 Oct 1995 18:14:25 -0700 Received: (from dima@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA17431 ; Tue, 17 Oct 1995 18:14:23 -0700 Message-Id: <199510180114.SAA17431@freefall.freebsd.org> Subject: Re: TCP/IP Spoofing etc. To: karl@bagpuss.demon.co.uk (Karl Strickland) Date: Tue, 17 Oct 1995 18:14:22 -0700 (PDT) Cc: dima@freebsd.org, roberto@keltia.freenix.fr, pete@puffin.pelican.com, julian@ref.tfs.com, hackers@freebsd.org In-Reply-To: <199510121211.NAA21217@bagpuss.demon.co.uk> from "Karl Strickland" at Oct 12, 95 01:11:04 pm From: dima@freebsd.org (Dima Ruban) X-Class: Fast Organization: HackerDome X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1192 Sender: owner-hackers@freebsd.org Precedence: bulk Karl Strickland writes: > > > > > Ollivier Robert writes: > > > > > > It seems that Pete Carah said: > > > > The latest cert report was a summary of the 'announced' bugs which are > > > > still outstanding on popular systems... I don't know which ones we are > > > > susceptible to; we are using the latest (or next-latest) sendmail which > > > > has plugged many of them. > > > > > > Speaking of sendmail, can we import 8.7.1 in -CURRENT ? > > > > 8.7.1 has a bit different sendmail.cf .... > > I would suggest waiting a while before importing sendmail 8.7.x. Apparently > an awful lot of code has changed or been-added since 8.6.12, and as far as I > know, nobody has performed a security audit on the 8.7.1 code yet. That's truth ... > Unless there are compelling reasons to go to 8.7.1 now, I would say 'better > with the devil you know', at least for the time being. > > -- > ------------------------------------------+----------------------------------- > Mailed using ELM on FreeBSD | Karl Strickland > PGP 2.3a Public Key Available. | Internet: karl@bagpuss.demon.co.uk > | > -- dima From owner-freebsd-hackers Tue Oct 17 19:13:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA20469 for hackers-outgoing; Tue, 17 Oct 1995 19:13:19 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA20460 ; Tue, 17 Oct 1995 19:13:08 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA29166; Tue, 17 Oct 1995 19:07:29 -0700 From: Terry Lambert Message-Id: <199510180207.TAA29166@phaeton.artisoft.com> Subject: Re: Locale stuff: call for conclusion. To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Tue, 17 Oct 1995 19:07:29 -0700 (MST) Cc: terry@lambert.org, core@FreeBSD.ORG, hackers@FreeBSD.ORG, phk@critter.tfs.com, wollman@lcs.mit.edu In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 18, 95 02:38:56 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4761 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Well... What is our final decision about XPG4->XPG3 migration? > Does your words about #define XPG4 means that Garrett > agrees to #ifdef XPG4 ? No. He wants localization to take place to XPG/4, if it takes place at all. In the runic case of XPG/4, he wants the declaration "doesn't work", and thus it will poke its head up the first time someone in a runic locale trys to run an 8 bit clean piece of code that sets locale but is not capable of handling runes. There are two approaches to deal with this: 1) Call setlocale() in 8bit clean code and let it break in a runic locale. 2) Don't call setlocale in the code, even if it is 8 bit clean, until it is capable of handling runic encoded data. The consequences are: 1) Breaks runic locales; it is unlikely that someone would put forth the effort to do the necessary fixups, since it will require the engineer doing the work to do so in a non-native locale (probably english) until they get all of the applications running. 2) Breaks currently running (with the crt0.o hack and with setlocale() calls in 8 bit clean but runic incapable programs) code in the runic and non-runic environemnts until a full localization. It is unlikely that someone would put forth the effort to do the necessary fixups, since it will require the engineer doing the work to do a full XPG/4 localization of the code, instead of the easier but runic incapable XPG/3 and 8 bit clean code changes. Both these approaches dissuade use until everything is fixed at once; the first in runic locales only, the second in all locales other than ISO 8859-1. A third alternative would be: 3) Leave both XPG/3 and XPG/4 setlocale() calls out of code until it is fully internationalized via XPG/4 (like option 2), but make the C locale ASCII only. The consequences are: 3) Restores everything to what it was before your crt0.o hack, but all of the world, other than the US, is inconvenienced. This both encourages internationalization efforts that will then benefit all locales, and encourages the use of Linux instead of BSD by people who aren't up to full XPG/4 type internationalization. What we have now is "almost 1", where attempts to use locales introduce state because of the crt0.o hack, and cause things (like xterm) to core their brains out. This is Garrett's approach, assuming he wants the crt0.o hack removed. My suggestion is: 4) Use #ifdef'ed code to make a seperate XPG/4 library from the same code that results in an XPG/3 library integrated with the C library. Use object module dependencies in the XPG/4 version of the library to cause it to be completely dragged in place of the libc XPG/3 code if it is linked before the libc which contains the XPG/3 code. I believe there is a shared library problem that this will cause to show up: shared library symbols will override non-shared library symbols. This has to be fixed. Add XPG/3 localization to all 8-bit clean code. Leave all 8-bit unclean code unlocalized. Use ISO 8859-1 as the C locale. Add a directive to the default .mk files to cause the use of XPG/4 instead of XPG/3 when the directive is specified. The consequences are: 4) -The XPG/3 and XPG/4 code is maintained in parallel. -Both XPG/3 and XPG/4 localization mechanisms can exist at the same time. -The linker bug with shared library symbols gets fixed. -The internationalization interface is better abstracted. -The benefits of the crt0.o hack are not lost for 8 bit clean code, but there is incentive to XPG/3 localize and 8-bit clean the code where the benefits are not lost. -The crt0.o hack will go away. -Unclean code will not bogusly call setlocale() and pretend to work, but fail unexpectedly (like the crt0.o hack causes now). -The default C locale will be sufficient for most 8859-x use, except for those locale-specific features that locale unaware code probably wouldn't be using in the first place. -The directive will flag code which has been internationalized, as well as simplifying the code that has not. Of course, my suggestion does not address: o Someone actually fixing the linker bug (for all I know, it could be fixed already). o The other actual interface issues for allowing optioning XPG/4 in in place of XPG/3. o Someone actually adding the directive to the .mk files to make it a "toggle switch" that can be thrown. o Most of the incentives for the unaffected locales to do localization is lost. I'm not a big fan of negative reinforcement anyway... I think all it does is promote Linux when we negatively reinforce and they do not. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 19:15:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA20550 for hackers-outgoing; Tue, 17 Oct 1995 19:15:40 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA20545 for ; Tue, 17 Oct 1995 19:15:34 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA29181; Tue, 17 Oct 1995 19:08:44 -0700 From: Terry Lambert Message-Id: <199510180208.TAA29181@phaeton.artisoft.com> Subject: Re: Very slot TCP connections? To: dawes@rf900.physics.usyd.edu.au (David Dawes) Date: Tue, 17 Oct 1995 19:08:44 -0700 (MST) Cc: terry@lambert.org, joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.ORG In-Reply-To: <199510180027.KAA10676@rf900.physics.usyd.edu.au> from "David Dawes" at Oct 18, 95 10:27:34 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 399 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > For ftp and http connections? That's where I'm noticing the problem. > The thing is, it isn't a genral problem. I mainly see it when connecting > to this one site. Tell the site administrator? FTP code does use Telent IAC on the control connection, BTW. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 17 19:30:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA20939 for hackers-outgoing; Tue, 17 Oct 1995 19:30:27 -0700 Received: from kryten.atinc.com (kryten.Atinc.COM [198.138.38.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA20930 for ; Tue, 17 Oct 1995 19:30:12 -0700 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id WAA24387; Tue, 17 Oct 1995 22:14:35 -0400 Date: Tue, 17 Oct 1995 22:14:33 -0400 (EDT) From: "Jonathan M. Bresler" Subject: Re: Stability questions... To: Andrew Gillham cc: freebsd-hackers@freebsd.org In-Reply-To: <9510171512.AA24607@edmund> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Tue, 17 Oct 1995, Andrew Gillham wrote: > I installed FreeBSD 2.0.5-RELEASE over the weekend, and I have > been having problems with it. What I am seeing is "cc1 interrupted > by signal 11" or similar when I am trying to compile a kernel. > Restarting make will eventually get it all built though. Is this a > known problem with 2.0.5-RELEASE, or is my hardware flakey? > My hardware: > ASUS SP3G w/AMD DX4/100 this motherboard is rock solid. i have been using one for over 6 months now. doing make worlds and all sorts of compiling--no problems. do you have L2 cache set to write-thru or write-back?? the board comes withOUT the sram needed to support write-back. (this sram $123 will gain you 10% speed up on a make world. thanks rod! ;) > 32MB > NCR PCI SCSI > Micropolis MC2217 > 3c509 (not a 'b') > ATI GUP ISA > Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. FreeBSD Postmaster jmb@FreeBSD.Org | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-hackers Tue Oct 17 19:37:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA21120 for hackers-outgoing; Tue, 17 Oct 1995 19:37:48 -0700 Received: from donna.cylatech.com (cmh-p101.infinet.com [205.133.22.101]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA21112 for ; Tue, 17 Oct 1995 19:37:31 -0700 Received: (from macgyver@localhost) by donna.cylatech.com (8.6.12/8.6.9) id WAA00198 for hackers@freebsd.org; Tue, 17 Oct 1995 22:36:43 -0400 From: Wilson MacGyver Message-Id: <199510180236.WAA00198@donna.cylatech.com> Subject: new Linux for ISP... To: hackers@freebsd.org Date: Tue, 17 Oct 1995 22:36:42 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 225 Sender: owner-hackers@freebsd.org Precedence: bulk I just saw a book on using Linux for ISP yesterday... I wonder if this will start making people using Linux for ISP... -- Wilson MacGyver macgyver@cylatech.com -------------------------------------- Veni, Vidi, Concidi. From owner-freebsd-hackers Tue Oct 17 19:58:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA21559 for hackers-outgoing; Tue, 17 Oct 1995 19:58:51 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA21534 for ; Tue, 17 Oct 1995 19:58:11 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id NAA11257; Wed, 18 Oct 1995 13:01:24 +0930 From: Michael Smith Message-Id: <199510180331.NAA11257@genesis.atrad.adelaide.edu.au> Subject: Re: new Linux for ISP... To: macgyver@cylatech.com (Wilson MacGyver) Date: Wed, 18 Oct 1995 13:01:24 +0930 (CST) Cc: hackers@freebsd.org In-Reply-To: <199510180236.WAA00198@donna.cylatech.com> from "Wilson MacGyver" at Oct 17, 95 10:36:42 pm Content-Type: text Content-Length: 868 Sender: owner-hackers@freebsd.org Precedence: bulk Wilson MacGyver stands accused of saying: Firstly, this has nothing to do with FreeBSD-hackers. > I just saw a book on using Linux for ISP yesterday... I wonder if this > will start making people using Linux for ISP... Secondly, I've thumbed through several of these books lately. They're mostly crap, mixed with reprints from the installation docco for the common tools. If I were an ISP, I'd be ashamed if anyone saw them on my shelves. > Wilson MacGyver macgyver@cylatech.com -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Tue Oct 17 20:09:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA21835 for hackers-outgoing; Tue, 17 Oct 1995 20:09:29 -0700 Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA21829 for ; Tue, 17 Oct 1995 20:09:12 -0700 Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.11/8.6.11) with SMTP id EAA02113 ; Wed, 18 Oct 1995 04:08:16 +0100 To: Wilson MacGyver cc: hackers@freebsd.org Subject: Re: new Linux for ISP... In-reply-to: Your message of "Tue, 17 Oct 1995 22:36:42 EDT." <199510180236.WAA00198@donna.cylatech.com> Date: Wed, 18 Oct 1995 04:08:12 +0100 Message-ID: <2111.813985692@palmer.demon.co.uk> From: Gary Palmer Sender: owner-hackers@freebsd.org Precedence: bulk Wilson MacGyver stands accused of writing in message ID <199510180236.WAA00198@donna.cylatech.com>: >I just saw a book on using Linux for ISP yesterday... I wonder if this >will start making people using Linux for ISP... They already are... I met someone in Aberdeen (Scotland) who dialed into a local ISP as I watched. Then the Linux banner came up I nearly choked. When they commented they had a lot of reliability problems with their ISP, however, I had to smile :-) I felt like trying to find the ISP's NOC and wandering in with a FreeBSD CDROM to show them how to do it right. No offense to Linux, but either it was poorly setup or it couldn't handle what it was being asked to do. The login negotiation sequence fell over at least once whilst I was there. Gary From owner-freebsd-hackers Tue Oct 17 21:01:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA23378 for hackers-outgoing; Tue, 17 Oct 1995 21:01:18 -0700 Received: (from dima@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA23373 for freebsd-hackers@freebsd.org; Tue, 17 Oct 1995 21:01:14 -0700 Message-Id: <199510180401.VAA23373@freefall.freebsd.org> Subject: panic To: freebsd-hackers@freebsd.org Date: Tue, 17 Oct 1995 21:01:13 -0700 (PDT) From: dima@freebsd.org (Dima Ruban) X-Class: Fast Organization: HackerDome X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 32832 Sender: owner-hackers@freebsd.org Precedence: bulk Hi there! Does the anybody have an idea, what's going on? GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc... IdlePTD 1e0000 current pcb at 1c6864 panic: brelse: page missing #0 boot (arghowto=256) at ../../i386/i386/machdep.c:887 ../../i386/i386/machdep.c:887: No such file or directory. (kgdb) bt #0 boot (arghowto=256) at ../../i386/i386/machdep.c:887 #1 0xf0110433 in panic (fmt=0xf012155a "brelse: page missing\n") at ../../kern/subr_prf.c:128 #2 0xf01216f7 in brelse (bp=0xf3c7f578) at ../../kern/vfs_bio.c:434 #3 0xf01427cd in nfs_bioread (vp=0xf24bed80, uio=0xefbfff38, ioflag=0, cred=0xf281dc80) at ../../nfs/nfs_bio.c:389 #4 0xf0166eb6 in nfs_read (ap=0xefbffef4) at ../../nfs/nfs_vnops.c:936 #5 0xf012aa56 in vn_read (fp=0xf28d6880, uio=0xefbfff38, cred=0xf281dc80) at ./vnode_if.h:211 #6 0xf01116af in read (p=0xf279e500, uap=0xefbfff94, retval=0xefbfff8c) at ../../kern/sys_generic.c:112 #7 0xf01a15c7 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 0, tf_esi = 40960, tf_ebp = -272640268, tf_isp = -272629788, tf_ebx = 135086176, tf_edx = 4, tf_ecx = 4096, tf_eax = 3, tf_trapno = 531, tf_err = 531, tf_eip = 134719829, tf_cs = 31, tf_eflags = 531, tf_esp = -272640360, tf_ss = 39}) at ../../i386/i386/trap.c:859 #8 0xf0199e8b in Xsyscall () #9 0x8081952 in ?? () #10 0x807ffa8 in ?? () #11 0x807fded in ?? () #12 0x80838b2 in ?? () #13 0x1ea3f in ?? () #14 0x192a1 in ?? () #15 0x164c9 in ?? () #16 0x2f3c in ?? () #17 0x3691 in ?? () #18 0x2120f in ?? () #19 0x10e8 in ?? () (kgdb) Here's 'nm -pg /kernel | sort' output begin 644 kernel_name_list.gz M'XL(")U[A#`"`VME]\Q6S?W9#1J5#O.79WN^H>QK5!S6>WZ1',[3@+->8^LKB>#]NXTN[-,FP[- MC]OKM.OW$W@V,B>G=F9M*QTL?SL@&<>^'AM0_+KE<57FO*CU=>(S8P'5=;^= MB?S"=;BP=T6KZ]_+)JV&)K<*_*.5MD6KX^;N=VD62J19+/AH9[C=T]])D&C2 MDH!"$U`PS167\_)0RS-5U;'J)4)&31]1!G-N>OPYW%/D@((OMS\ORI@/3!T$ MQ$#9!"[;OAIW'%Q@NCB4>P9%NYCUL5W0Q-A.FGRKT]R8NCX-2!IFOF3$P*GV M3>WVM=GTS;[M6`[+&:MC5,\:$6I''&G7ZECY6/U9T&Z(]%P>CA::65_%6;^> MG]3$FK>_3YY4-Z@X#.WN_:2O]D6O(ZO"<:[;SY*Y0Z-R%I/E??KGH#W`G[[+ M5W9SDX1BW6'VI'&QA)I=W6E/I>\N:7LW]W$8DE;#0/%*$,!OM@S>/+'I.L=S M\"3-XY;J^3I^9-[OG>?57WWXAHCZJH^52N)C);^I\V;6IV=:3SR$57?Z1&8- M*P*QMUIX*GW;<>NB6NMY"+\[GD??=6AHUHT-3-^W0+E6SXOD;?R"L,F8#RR@ M2#&[D=7&IV7I)XW^DFGK)V,@QY+.IEBB=_A@+%$L"?7=^Z)..@=8T7O%8@W8 MN@(/DV`QODW$M3SV@-XMB:%TV-$_W?7D_CDT9%':= M285T?.S13)W[\KSRIAKZ.G5X"1(/9O&CPM@6$UG$6$0;VLEPH61*,_'K+D8DXK":A`!X)N]$QB:W M_`HR$(M;%MR_'IG&Y2)BDBZ,4-X`\ZX96Y6JYH-N'%,'SY46%9"G1="%X_@- MJJ1;DMQQHJXQ4M;#6E09U''R$-]?U'VG11]Q-XG3"=NPE/32.UX MMN:"=NQ0<"WK=U6!=<%'Z8>LBUW?;K\KMB_3,.<)V:+)H(W,:+M#+:9QEFE^ MJR^7*X\N?>TCV@Q\[J39,#VR(9DKV!NQ$'/+'TER?82#A&&7E?EY;N$<0)>Q MA*H3+;?AW&>L[+]"`^:#3QUMMS_'LDH_(SMK#!G-+DZ-IA$H,\75=O6].V7! MV,P1^]X7G!*SFO-`>Y)`Q.$L.VBG^C5_H.*QS.T::AMLG5FSEE%=MR_K#LC' M^Q86#X3WYW;-R#@<]:?;M^O.RSL[/BQ(>]XN4]].W-RZNY,/\#"VR^]_K9H7 M2U53^5%B4R+F*U5S@EQB=25-KPDU@EQFK32] M[NMK.T!9B+25CE21QSC"5(0U2E@:MFT$Y:FTH[#4LH6[4$ZE:X254^EF:;SG M'GL^.2-,[7M>Y-B8MH)VO/AJ8`4\7D#\.%A]K2KU#"C4CJ=U6"! MQ+E0@Q?QW=?6204@2PX M_)3B9=QC34::T1J$=%\>V#9*\V>MUQ_8B_!+:AJ,](,[KOVC#P^QJKO97Q'I MVLFG[:]#77FVNF%3L[_(8H+@&%D>2=JZL4EB%.A!6)%R0$@'_+*R=#7BG:BP MUS=<)$T^(^HFLZ$[F]P$XJQDNA\ER@RVY*$.-LMZJ*4#.APM>0K`#41;C#6P MOQA8/@3TV"5*<\L=CRFL);4,?0.[U#&'W)%.:7;J?A9\9C%^+??[=F6?0L-: M!L9`#]PEUP)C';A2C^2=@6E8M`_(ZTR.Q%9BP]'M!W,LU^4HH(&9"U$$`!NT M;3W"0C&KV>[&">XXY$S#&Y(J);_+-&R*0\(@A<"F9^.2O0_3YW/D>.D=BF/@ M1[^6];'"H30#[Z17.)DP\-@B]#IN26G,B&E_TBD?L<>?I[G)2!/4>WT][;YJ M6`#"O(SF1K+:>(,81*+G<7<.7V1J]C>?]H,B^,O$SV>(QICCB""K]<,0V;K8H=&3@`2H`#%[ MX6!8^%9%=>8C&_/;]P>=V$5`0+G@>+<3C@/&N\T%;&E0P'X]E\QC]='DH\S^ M:/5"1L"JC_%CJUPVEI/PBTA*=R6GZ$K4V5H^4*GJ_>(R1O@?C'$02W!P8H%K MZB39PG6+F,UI#.PIY/R#@E[,]X^"EA>U].@Q%02FS0JLNP*GOJ?L M(__^_5M$,K&)VIU>5UX>-\,\TP?>R-`\E7SXS%(*I]F/`M65+>!1N%E_U$^8 M#=;ZZ[6>"HCWHH2\EW0R.R6IF#28'N7PM&M(814ER>WZ66*B/@1S=J$PZ>NX M+\E]<`:9DF!8<#0XQQ::6`K@G'.H=Y74I8-ML$>.Z#P<+F)'"@E]YU`Q3],@SNQ7F5RQ)RP)),ZI&\!)3BIJX8W);&#G'O>\T3Y^"":C6M( M14K=),&0ODMSVG8O7HP7LZ3V25_ M5,<:*@7%EW5LV`%LC"LX&@<5^;" MX>6:5:4>^$QTR7TAA.-_W9[K>;RV33#[.:0GJZ#H?U!#LB5/BG:-S&=HTQX" ML$8`YC?Q*"G\#C<64R*HI+A2,5\+'R9OC*:26.Q^&,5JV=02`=WIU'1@J>GN MR(6SH*/08ELU32-?AF0\OJSIL(EB:HO1P*8W$OK"7TS'2GHXR!EWH@D-DA;' MNF;Q-"/+-L`LD&;$A(EF"313F^J64IB[U*_DD`F.">:=V MB:7&2#L1>A4;HS6(AP@_[1J\BM>!3BP$BZ)TE55W<^I>7/FZ4R9/[B:3ZQ!N M$K&H9Q!`W!Z0:>=JA$BWAZQ)AY.M0'W#VDP(,7[=MZEW^'Z_LG-935:I3 MXVS%IEH^_;ND324?OSD7;KV`12?(^_M6)_O?-<6,62LX.*BG`7(F?0B"!C3R M72DQDM8Y@4RTA>;&^TPEMG'"14><`I?"NQ3BF&+R;T*?)@_=R MI!V2)JEGW.U1O6+?SN,@M)@FK"N)@WR/^:@L"S9F1>K8] M;DB#NY,,W&QY\YCL'5V,3I?4]8R=;9)3]5GL*PES6.U4Q8K_ZW*N%U9ZR4@_ M;38O"H\D@G(SZ'AGZ-".]ZJ"\_ETOZ728!%FY7;(MQB%':XF+U^?K7:$H59I MH-6,W&_12JF5J]$+D7RV*,?+OOGCOGY3L(U.G)8Q MU7%FS/L]3OVA7[+A"7-V2>=)>P[V'Z09V>@H;-`'685S9QW5%<\7[&;9&&AH M1<#4Q?(`Y?J6CY"F;Q2"*2;0! MEL'#0?)1WZ/@D*4S%DF\E33)+9SUK>U880[E,RS"R-ZM>[9&=H+'&W)`*^9K M%9[`A'Q1@@97$.M-'>15K%XK3,,:]V,5&BQ#+(F-TK<@-4E%_F>10W=V3B7V M/]M96;&R5)HZ/.M9G^X[%-6,O40OOY;G\0L1FT7T371W#Z&NJF2QU/,,HGZL MNQ1)'!6*=O,N2CA]<^CD<3JY&]`7N2XAAG3L6IRN9+TJ6<3#[5A$)PJL/VC# MNSI0"D`.H;A9U&I+V]HUXP23)4FRL+HN+[ZZ(LD M>^[K'6588AV\IQT/RVJ'F\-#9V5S8X=N[`Y/P,U3@73OG:X%BIVM=-L.7ECLF(XZPK&R/'ZKQ^LPQ:86 M%I6O#.+$IX4F>+G2"S<>_`D>>;6\E3U>/T9"82Y#/&7X9![)#_.6`1#)!^3W M]0'(";WU!V7K'"D3F/I(TB"3-])C8K,U90Z8H9*(^0R"$&/AE99$_@?&"ZEM MP4GOC2GKA>0K+XRW\_2C`%RG3/:/`ILNF9W;BYZ!KY)ZJ9UO M4`G.Y43!;%+1U['O[A<4U'L^+(J2P)NJ;\6)*YZ:$>:\8L#YJ5E3X_.#-RBPN?./`Z4)KP*DJ%Q4*IAR&^Q4@B[5)K-WT2/R,ZG']1["0EH* MGGXW#FGZ*9]2TB";DO)^LLZKU_V\N'WGMVY4R,Y+:+-N[Q3/-_+6F@M*/HE> M9::X+E7-@633Z21B7E>9C^8L73@B%B;R'#,OO[Q_IEU M:4[]D.:9/$:"-F^D9\9C_;%7`$?SN;L83UW1Q2-LUQU7R4V/8Z,HPVOFIL>[ M1C(8HH*]:@61>^WQ=(XPG\EO.M/VF.)BK-,13K7C_U:8VQH6['@\3[C=1-FI M>V?/N.GABKV7YUO=951J8X.U%*>Z&28V&>]H&!G-^'=.N`B7]1P4?^A;;L>;`:]&WR'+ M@HN]9C#81=&N,[(XWN(=)R,WE^]*\N(.^&='4*BH3L[R$[9F;.JDAN[WAH"9 M\%!]XG)3C4T^1Q[A#1+3MDV[ZB,TX)*0/DB3'_$6$MH-AMO^]8/BRC`/,_%' MQF<08B/&R:>_AV!;C#.;!__!K"B_/^3"K!D16'MSLQPO-"-L2TD,U"QMTQ'W M%)+`:T;<&W!V`PBYF2]:C$BFFL^WQY=?.+7>3`T>;2]/-B13!V?WSR.S?H+( M,AKP./YP#@1OX-<2I7\,(0IL)OQM9DTBF&;>"]0N(?PYR;S/S#0"Z@SPO"$3 MRRM;_H&%H)+W/#;/'MIJ;OZNKIB9YSWB2SA7`RH^(,.Y9N(+U"!/>A-_><:? MV7R!.M;V5WCD@\Y[W,SLKZ<1CVC_I!,;G_4'Q8O7GY4'_+='%'>&%[$[ M"6J:V530#E&SV>(ARB,1UZ>(B!AY,/N"N2MD,O^?$KPF>#>ZQ>/ MKMKDCV93H5HENSC\,U&VL&H-_D28U5U!LXA%9\3<,!1>(KZ?^?Z9H);*.[G> MS/`.+C!QCQ1N%*53AHAD""9%4TAB$4L9\$9!6*%B2H`351\3DJ=S5!!O)BP- M_OFU3OY]I&QI^!0!_BQ`MOB>?%QK_Z8C8:64]L,^UB2+4U'#I(\X/0HC' M_\P$:_8AQ,CCZT,J*(2HZV%*/`E1RQ_5`DU"E-QXI%F(\G(ZXBQ$W9L\8B%$ MW1=]9Z$,^-<;ST\$B&O.2`O?3@]=KIW56N,=2,11LG)AVFC\F3$7`7=Y@`\K MJ4>5^RJ6`_\*CKCX]Q$5F.*S\CKQOWK"$Y;@ULOSV$:K:9(_?E&!S6+3?='` M;[N[IC6$P4]MN!1EOFCVD,<>C4:`D]I(_*L19\I`X7+)_18W4+MR%L]5_K7+ M!65_H0PE\[_[^K8E1W(^2_=OH&6+11?LUDF]ET0 M$OC]"]UF"TALHJL7D M$U35BF!F4%;:6@1':RY=(2.\>[4YJKK'+JX8Y_U^T9[LDB_IZWJ_S.]*\56V M_5SL/-=Z>94I)8=)IAA:CY>Y'\.*88HK`5V3?"ZG3\88/<7) M^CBOBF.YKGI-VG;9&>LZQ=4P9#S[;A+!%95P"3KC-CBI"M%06S82/!DR6I:- M%*:2N`Q7PFV(#+ME(\$-!D%X)_6Z9M2M M,VF,!2^\EN)46E1&/Z5-JRXCBE^U2!"R5)6F03;H-3=6"4EB:.@IJ$$ M@_ZA&&T3[`&'V9O/$T[>#_-`_WX?[N]Z;K6;X#-52(D$1Z'*1JM0SQ`#$ZYU MN2*E[M-NIP5>9OKO=;[<2GG5)NCF:G^[WZ;/Q[2@0)RL4<=&0CO4X/49\9S4QC1/39BTS!+5^^G^SO)_K+( MZ#E:QO?%)6\WX2ZW$,S)8C=A(RJX\X+><3`5EV-V(S9O=HY$_7=Z'.]B6)MW MC2LO34='JFO4FN:JFN9FQ!A@R'\!WN$$ES;,4+B.E_7@S"VN7!?'9<(R-]+@ M'G[JIUHIDV_W3,--OX1S3D/W(F)GW+/*UR&)A;%=FCLKQ$F<.Y-5FUVK9Y8)OQ:$* M@'X/QX\[V\/UY+#:P!+IB(+C=F>N#\T42$::"Z%VN&!]*[WZO8^C=*M@"RZ%8Q=>##5X=9Q&ITL+]:9S@R%)J,M2Q@."0:@,!FBOH?(F(,!BA M'.A5FY35PMRO^C5(PUN^]>`^"'&6TWH8]X_NYDI4;>#/!&Q_>#L#KSV^%7`6 MA>UVUV.L:KMI5:XY#"VC<>,=//ILBPM7M^)I2]CN22P6ON&9I<78!*JV78/" M\^7F01/KU26.=[-\3!8&I-K"8D:?U8[8CEE=ON7C5?1EQJS/7+]O8^L(98I7 M.]SBEIJAZ+$Y5>:P+#C4KMCJ#O@P%W!2D&8>3QRC=*T/`\.W--D8 M(JW:A<8;10\S.Q\(97T-3WA#**,*M?L#SG*,B5_MX^PFQ`[Z$J&JDU2LKP*S M!;S:39TF=.M`M5,'9,I?.JS"U7I.;$DK!&PB4!6=JL+-!,),S:DJ7&(DL&@S M5=4W?GE!JRI<^QQNU^]W]B$2%(,7"L;]+H+U4DQ50]0S9E6MZT9+ M=9H"P1(XZNV$A4(0YFJ"]BY=BG9O\28+354WNF\^)P<./K_V7SU,!?[OR^&< M;^<+"::D3,KA%3PM%9KW0ZSJ.!2*7^^K&G=?A6*G5H0C.)2V%!$=#KQNT"Y% M0`1T..1H(_F*(GH5!GLBQ.%,ZLPWSM*),N&<)KM"T%22A:"!D91S%#^@JNGT M%)H&8HGP)Z\:6-4S;/W>#(-69[Q=AA0'S)1FW"C!ZP55`TX_G%=*0=6DG31^ M?[45)6.2EL`B5S7BCN#J4E$UL),)7'JFW]R_&T#+7;Z+*YI:O= M==:?XD52/K6S(5O$&\61)E?<^7(_S")MVBI%&]$%WG%5B_E`Z(V=Y\]RL$QX MY]I>5(^*]B_AF<"WP(78;ETN4C<SM=MB:6.8U#(3 M61U<`3)!?;((Q1W@J]XMKCJXO4O",@D[N2USP-=0.T)10!$Y'2PLAR+9.CA1 M':YR#"D@_"T)Y%5\!CAIRNDL:V&'F'T'=AY2:*=95Q*D2R)5.:EU=Y>LR$1* M-(> M!035<5E*[>#.NBK0JMB/TI="]9TPX`+Z#UHBWH;C_HN6S?-#).W0;>J2BV4D M][F0X"%$7.09?-QUP?<1EV95)%4C/A.MAF.S6_4NU3%.C@SS&X;$OM=OT/6B M4Z#KQ]X8VND:$3!$:"=<_+75&IS$8NI[C4\(5+J*PN_[*K[N: M)MS9(NK/T^&^M[@)U01S&Y-.^/@,EPM@`F)CQ7E80D(QZC?DC-M'"OO7F[$,O%.HZ@U6,W14895Z@_`B3"D[)8)' M@]?*&36[E$6?SD.70"FC5%:CFF^PLX]O>FK#%GX!3%"FJS4JKH!:2[WPSNAJ MH+>MZ&1,<*W:XI)-^:;`XV"I?05CMGJ<%@MU7>%:^/GI[(,(DY7L#C[J*A5<[=1U-556XV(? M9]B^>%@8!JM4./H_KT]!"`_6R,]\.T/;.8FE]_RYW+YR+#6]NE'75>G[C.XM MR$G-O5:RD0;&,5J$@LM=0B&]G&?=)TBS^Q9IJ>=!FE[CR%H(K./NIZ^#A1BK MZZ%S9;+K+ZD`^QP1YQ<2S"C@G,]K;E^3Z#"TB6Z"49Y;V"!^KQ*_!O9]381%';5&T^ZBC=HTR!7<9.**%AVONDLJ=<-4MHFU;3^JI6-WM/,6= ME]5AMW44MS0$Q#,0@O>)JOMZ?")E>&BJ4C$G(T9L>1W^-K!U)U-CM2NYODEZ M#\=ID?@5=:RMYYFVP/&/\&:S:HZ&$2?*4'+LR_V]>MIN719S=*MG^%]I6S3^ M63T7`9,)>IK=;$)T)6FG-%LH9JA3\8EK=JO:FA=54R&*(KYP,GQR/>)/(YMF M2J^4ZU&._YLN^?+BY83@@TVH1E\U._YNPAA=#O9Q%J^01F^""\$?V35]YUE) M/78)GER.\T7D6J-^9P(77FWZ?FN\[2Y?$EYDM5M]FQZ'2)#**TIOE/623:39 M2+HS;X:--6#OKCXV0YW<%Z['7X*&VJ%FMV[&[=:5M=2&=DKUJKZ%E"HOVD1F.VI=.6IV@/;$P>KR&''H M3ZB-+=^__GP7-!C'$GJ-Q@K3UACSE.^%WR\/T6F:J0B]$T==O%].T(V:J8TE M%_.S\-OD^!"!B@@+)2E'$"F%1)-VIF(VT[0I^L)E2+P&E";/U>0'\8G8M$7; MTIL,S0SOF?Q]W.%NYE"7IK'8CL(D,P(#*LYA+O.YJ\R$.3;!D^="F68OI,RM MIMUL-GJEGTU,Y?B3**6SF"5H53M,0ME:+?99)85H)4(JLNPW10QPB2=?NVVV_HLAPO@,+EZ_S5.4^^$#N%)F`C>5FY!=GA79A]PDJ29U,3">D4];=NI M=^NO2%P"HU_J3&,EPA2>"?J!S@T\TPP?-NL-KQ)"%0JGL"*IA+[9U"L"T+(7 M+`II.\"13SZK:F<[])NPAL'_0V^K*0CZV6$.CJ)Z:JL11`J,DL;-N%D3M*0Q MEF&POHM=T/,`>H_&0KZ0>WAYRH;IKH["-4DI-6HU,I)12%7OMA$C$47N] MX=9UFW[C"7!2[SKLP!57GNBZRG!:F3Q%?&2(P&$SJ7RT)#19TXW)?N,&6=*5 MEZ`$2*4^0;(44"H]X>H"#GQC*CT9$*]7CXAPJUI'W>OBQQ.>Q'L]\1/&M`Z?U/:7X_R&*4[XPKIN&Q.3NSS#X. MUR$BFCB1I6X@TQ*YI\9`<2`J`@PQ5?#]"5>ENC[6)>N=MJ][=OG,WT#9,90$ M2R31`P1#*=%XF4G=H;SL?<()`6Y-^\Y2BR,X!]YHS\7&_ M5"/@MGRO&FF_!CBLX0/@8>,+V6DA8TF]RX)Q'OS`N_D8MR4'[;F`1:U1B030Q9V^7G5GT_1Y^@;< M1`?C^)[@R:?6213A@0W8Q4@B4BJ3,['E>UK%;^RB9Q!;#]R8Q>"8L21P(Q?U MD3A.(?*/OB1]%/LNN,EV&2>^N+],H`[I-U0A13?ALFNYM38Y@9(SX1)W%VI9(_+/QZHV.'QX?*RKTDCX8UVV$_P= MEK)LIP:AKLJRG?0=`[=L)T006MRRG;#B+VE=%5Q,62_;"8]\+7[93BI)W;*= ML*%:_+*=X$R]/"W;"8ZLBUNV4]2J^G'$`=+BENVDJTFRV`S[$GZS2Y-V0UZ6 MK\/M!,(,&5V6]0E75;GX+!UI@4Q'S/L)[TTM2=]LT.XS/9"X=+ MB1G=35#79IAF"8^B8$QC20\*Z?A2RQF/CLQK_7[&<["S[`>NL*>$#V>#RS$`1.EOQ03FX%1FIE5@:M M366W$;9S;R7[W4G8B;%X7MUS%+0TU;9$80K$G5)MEW)>9Q>;XN M5-O9OGY8[.6BP%[6I8]NCH#X3K.8,3QATNK*4YZHL,.]48NVOF6(5V:J4.&Y M@=F;J4(5DF,D-NX*C'`0EE@,6*'&&P&,7XYI7DKP8J*-A;M.^04KS33;EYW5 M*]2PG,ZZR>6+Z\@".3VO;'.AALEN=B:Q4#>[\ETL4Z'NRC0H)C%2WFK[9#&) M$=A:ZF5T;%3WQHG.^$7PY*>?]!GM`JP0VZ&%!K&F9[^_#XULGAZP&Z!8#6O^ M<.:$T+32Y0H.MYNL=:&!Q>>!8^Q1_*M"(W=2'G*L]>'87&/I9!A;10)E]8N7 M&U_1@,UD^3@.XW24%`C/\AO*9,\;/1'P"(H6FCMDG:2%N?9WI"VNZ'^0Y!6_ MQ-#N.JL[M#J.V:TM/;#3!IJ9873,P;\N%=1_V2A%1Z%UIPDKFO)2VVSC4W$+ M"/".4<)M0EV;9/5R`JS%%8^'%V!M6SNPN).$%B_5/=;N)*&5FPZ/IX!1A'?6 M:M>L#A>EA1UN([BUPU:ZP':G)'00_*!95+'08<<'0K$^!O7R-4J9`1T.'K6T MT_6.S\REP[,(99M6IH1-ITW,MFBT,)2`(-2M]E`0X3."HWRD3T%PIIZ1^/XF M8*5O"7P..\#TC.THDGGCXKS2N!_"H8%(_3VXJ2KH+YDM`)A M0%OR97B!X%KT:8(BP"J4[$FQ$!+>#_Q4!NWQR%CZU*6[A_F'$3DL"OUV!\@* MI_T@\IF-,?2BACR>%Y:^*CQABA6C-H2VTO15;USBCQ)"CQ``-N`N)E/HBTCT MHK9W,K$8P0E.]@VSF(?>,;5JCP26>63J8^AQY_^Q.JH(?2A3VIT_A!ZOMCS6 MYP^TD2\=8*HEH>63Y8Y2T`=*'\X`S&`L:26J$8&]F_LVRP8\`?-P9O8PX/SU ML;+BAV$J(?IL;;4$X<60>JL[V%LO6@JQR5$*!+.>:F% M$;X?#^<"%[(?-\#B=A#4$>+QY`)'A-)0K_*'<=P8P4PUA/;:J)69F`C6JK69 MF"A6_;69.(RX"O1X,A,3P?AS;28F2@R>X@K#VP"/)SL^$3PDJH"1`1S7M'*SB)$/".ZIJ=IE>(W)7!` M6XUB&=3I?IWD^E@E&7Z3A!;1*QXT#?EE2FY$WL2OVZ"!?;Z0S_I$C3&%Y"H. M)]%"6S4+IU*%NFY26S]]<]TDD@FOVJ\H3Y\=AM("-E*3PO.X+:H*1:BHF9R=+)X3R"'%\LUG()Y3 M1E@3C.#Z>9R>:?E_2P+X**P27#U#I9?2'1%SUA'9*8I^$5]$5%OM"24-[Z>? M$N'YE^=$EB`A>/Z+78$)J^N<6^#F1VI<&>K9...#UO9MC]6Y! M?FG=:DHEA!!V]-6]3 M>L`^UF\0JY2'Z/*XYP`[**.-&T<1K.O1UA+/E\!1A^PTG6Q6DZZ\0V+N!4T, M)[D/3BH!$+@K5?`2761IH0L,R99AM801*L:DC-+NVZ7'\6&FG!P^[9Z*WVL8 M;*+%S>H;[AWB?H.CZ(]U$V?E8;,M$!:L.X:KJ/!6R`12EBFN?5L-L3AQ/U.&9WU?Y\$+X]@(]-]`[;8V!31O]3)FQN\F>74$+$:)E6>X*R`A<=%G%V4._ M@\E%-YG]#F=S%T,J?29*E]2^@NO^*?M_`!(6$&A.`$7[/GGFK':R,SW1MN6` M&5MAHW`JSP80AH_8&E+A,:236U>JJLPLJXL$1R+H,OXW?1:]5$%),+R(G"K8 M+`-I)16J\)QS+5.J_CG[DUBIQNHI07Z]\6STV#_1\U)>9F"],5E9OL`&0"JA M+.6]AL8OR212OP;'X+"_3PFN.G-`G\)OZ&Y>UKOTU!L!_.%8O'R[W>(C\/$9/VA"E4+9@"IBB3C9TRX0\-CGJ M9,,B!+<4-CBJ4)K>!.R;[6Z5R:TA#9ZI5))K7:/AQT\O]6YVS[G4E5C6ZB;TKY0<+$5EWX];$FM^O22<;L=4M- MU'Y=NS&N\ZFF!^J\_J@X<19ZW*US#S#-$J5;MP:"S36&E'=R.J+Z9-ZWM^_V`8]OY#V?<(0^ M,R"0G.[VH6I0YN.L$10%9-6'GU,2]2+@Y>G+E]-60BWO.[`1=<5F`5&,',6) MW:#/;#BJ,Z'T`4_,>[JSH?2A:UY*YTA-NEJ%#@/KZ`\[0^]#Z#8OY'(?K=>W M$#R=!7_Y?K]Y;1U\_X@87XC%D$+DZ97,D0;VR^DH1_8DE7;Q]VGPYD@?TFL5 MO9VH)UWUI8W>4-3W<'7R"4R7[)LL,(?'_5(\_P25Q_6>?>Z8%M>T8EHB8K\F M"MK"1C?=V:$'OFU]+X8)_UVHJX>%M^PE':++++SB%13!:/G)230FC/I,Q_V" M<`D]'(CI*XM^!:'_HKUZV_T8+P$81CTQ*#C[!9 M/Z"'7GT?-6LY\B)0#+OQK$\6$Z25R]L_!;5`?6J8V@"7]#?\S)-[^LD/)-)> M49L*G_\?Z?"E@`192J-FE"GRXWPZ*"`IQBLJ"<>B'Y?YJ`!28$O?XX6/'ZJ+ M$("OG`<`LAC19['Q[A%R^,=\?2S3VPF@J$8_[LNB@.3C`)$(J,:@9-6='@'R M.=YS`9%>_&$SN8=GYH_;\J6UEJT_UT``["!_V&5>@A"P"C<(`",P+-$&;P$_I*U_W`]#6/X#]?+_5`@?':H"X0O0@+\<#V+L$T_7*]&5R_T:'3U0F\F5R_M MRX7L/%VL_$_J6T-7UXJ<>*#G_YZ_$O`78(H;G/3DZ09R-\,A06 ML,GVH5/V[59E:42(GWA]K/:P(_1/]BOAL%+WPR(W&_JX01#TZ9P6[`HC@C+3 M;ZKXXR92(5:B\Z3#)'\$Q5VU$9X>O3ZHP&O>\@L?"1M="O59"L*P^'!5BRDL M]@@U3W5,*!$'C$NZ7Q:Y=$Q+B';)X5X%8=.$4XLKZ8E1-E!ROX\H\BVED$P] M\NH^74$6]@/YS=4RP2FWE.E(L_^<'(R*3$VPD4DT5\L`>YB<91HHFLZ?T_AX M>X.5,"'6YD@Z75*_&`Z`O#=_.%H)X:A#>L"SCSP1\QTS>Z%$@&S]*^MZ0CSW MT\F6_P17T=-)7NCH$[9D5))9W;*/-A5^B+3P'$YJ8%'7;<,%[?)5X6NQ82:] M5I8W(W=-AC<=LEGY)W>I#'["*8RFUCT)B*$4]>!+.9HIE=(>9T_!3>Y,65D@ M4C^6#S$W\W8##1[FDLFTIX1X)QFUOD&@F^O3$0BMZ*5&UU(&-N$9?KM=OOG\ M20<8H8>OLL^FZEQ^@3"63.YJ"1%B=`1ON$QSF2_[Z]?>O9S53WHOL!@`G7%] MVE;AB2IXT]3/N517F+K6#;$S"4]XSOF*TP/P^X2=:H8_'1[=-S[]QZ/KFP^? M(9:"/E89IE*2,PHK7\P;-_JXM_9]N*GR-6\=HYF-:=ZN:F$CI_$',Y[M5<:Q M,ZQ_5I`G]8Y%_''-#!7&*#1##@OL67/U3/0=/L.#1:COOY:\D8-G&U-+`PY+ MX1D1LC/.595\NB2^$PH)T$SJZID_/U#5#SN/NJ2,N[OFS?M;[K9A< MNO^9DW__:+WXS:G?/+V\4N3LG%8/\(BT=M3TDK6\^]3/T%E6F5?T:O6ZCZTL M\U3'U?M//U?$O`M=7:$5D'+L]P_:O2R'2M$HZ`K4B/L1!^;VN( M^1#(8(O3-Q!]1.QX/`#!.\L\,B,@F;H90C[$\L[03T!U@5;(Y,*YRPX@`63*.;PE]OA-%X7@H@/A9'16`Z>6HWX![W9+U,[0/ MYOS\T'64C0N!HM'?'%`#J!3PV11L5'G\;ZUUU<)[[/Q6,)%'^_TXBFB?'V(F M)=(@GF#WB.L``D$C=6[I>'%+'K=N9TXINZZ^QTB55:9:LVU5/9J@8.U;9= M^X9]/@YBJB12;^RG?@V#GJPS2*H`"MDUMO=33R$"10`PR`?N>K60"+&V+5GZ M"^9;@O&"'W6H*D]#A9`F'U\X(!BJ6D^Z!K7>#_QD0L;R,8.AV!5P!7*L`:"R MOK#**X"\41>+)^R@@9'B\<.D=87'>(:8HP=(4#P1)A7.=U:D'4BUGC7DB)NK M7.TK27.%:,NK?G]`6`?::HU\&K&/OTB[R4]43T@R2M?\^6__^^__5Q"8NVER MC=.$#D0`[[Q)IR^H:7JH$)6$>>-^22ASWN$Q8>I`0^MMM+'-<>SL4NI0(P`T MGQKTFS\:6/+CO/MLUW*'!&\2',Z$R;QLX4/)Y9,%D]?V?=N=Y:*`$S>5^\]#, M8NJ;5S>9AQ9#,"?CGA8W@N=R8WKH8/&9]S8`7407VCYQZ.8`R(XDA@#_C,G> M;Q@"HHY,5[74#P%NA`SI&`4\X#)=OSG*7;J\`1Z"?@3S/%\0HMHMN&XU]#OI M@'=:Y)9I.M.V8(!N/O3Z/MPRK(]"AAY70'*L3<)7N08]_1B>S1@#6QYSC7Y/ MQ",(1#N.&_0*V/EW MM"S3CU?L;88!(3\)R5$B!,0E"@++E7]"DZ(V^0:]:'"]E]DWX."=P*+.#.A_ M`DMM4J6YR^P;ZSS[SE><#!._(6K6]:=-OC',BMEB.\):E-/A"R/>$B(,)T## M"+"F=P.L%&F5"F'S"3,(D#=ERX#/.^^4N[C##!(,E5_Y,V]%(4HKG1^";7X2:1?8>YU9A" MUNAQ`]>H)9HP'#>A1GPQ-\*C/M?(J`XP@1JZK(S82`QJ*75P"80%,'I.&%5Q M6Z*:L<<*,I?-\2-MS*7+Q[K3ASSYX?CA2`J75*P.^4C]&QK,6",8W/=JW1\; MW/KZMG5_U+?$ODV1&-MZB\PV"OS<.K#2;RTB('Z;]C*VS01(E?FQ%4O2P7DS M*):'90T]3I>4#M4:)(Y;/"(F*$D)5.+5I,.7S]P[:U5)FJ4J=-5$MK_J`CFR^NE0Q%A=X/;^\`JXV"\T0:OZB;C&MY^R]2T<#UB(&<>.!K5B*,50H><['^EX_0?__6G8KD\-NYNKNH@1?"8DWY=KG:3 M5:.@$3'52L2E@Z_K_C+/O%/3%/$I1WL7)9B+UF;30U;U^O$[B\HVLQ.VR]9HZ;IQ0N=^E,7F5?\TYQ12\YJ]*-.2#.2U:. MOK]*X/*67N18":]9ZWI%=SE+)^(`\R5O5S^E<+E[EYL=]5]S#_$IA\A:>1PN4N_3K^;GXV13",Z_G9 ME`Z54*`O68M8D`0NK^M+A.YXS5XD@Z4I);2E,S4TQDL);1$0EL:54'H4,31> M"RAB0I.X_*57-13<:P'=YB6-*Z'TK839>\W?QZ<4+G?T4TH#^+T6$UNAY+]GYO.#CK!V61 MX,,49XIG/*YP+4*D6H:E2Q6O#6=;R7VPEK;E`_?+<;H-\"MA4OG&E63O8<$E M8B)UY3NGX:>]TCSFV$Q*F=B*Z2CE2_P>M7ZE*U]Q/13*!_"$#8.E[-LTJV<< M$63GD2+QRZ(-$XZ8?DYQ^08DZ]W9XAT0),H#M8'E5)JN$B.-"),0II/>'!RS M[?;/?`1],^X9H&`NA[4RW84,E_;5P6!72];[$^,AX;I'L_'BSMG?2G*^]&6T&?N8G\_QY,0/)T$F#Y/&NRQ7-Q+PY+6_Y'1L!PP:5 M.GEPJ^#]@IX,,AF6]U4Z<-K]5V)_2P%[X6N:M)/V^2#0>84%C(/8U@C`SI'E M9!G!001]1J/>R2%8>N(TWG]=)]1FD-'B:V1'_$PWR]?'`9_!(RUYGZ_'&8'R]CRT.9[18O"8E=X++^N ML&T2EEN>V6P+2%;G#[8][+\<`T8,".UK2GZQ$^14&T`R0#D2GB`)790WEURA MR]5[=H[#U+PFN%R_RMHT3#(CNZ,O#]<3WPJF5]E/VD[ZSG]DQ20`OF9]3_9`/G]-&F)4BME/67'1F9+ M?E1^GR#QQJ9V*-Z%)[1Q*+ND7A2O#8?0&YL0#'-";\2NXOXXE]DR-L)4P^W* M,8`>9ZV;:*X9_H";!:/!T'3YUG)E`WT\YJE(1(&QSZ#?O#)]`MQIN=QW;L!; M,5*2XG.\7*[Z]"OCT4HYW"VF"!&PYCY&$M#+P*&5(X3=B,T#VVZU4X)H9PSY M/@F2\G;_%!W_EQHNQR#+,E/N%\IQ_J5X4)SXXR53M$PD%6U6!%G<#O%T9:V! MW[`$0184)0`4?KTMK!1K167-.%SGR^U[N.E1,Q."$)CO;A/'?XU0HHD6A<;Q M9Y7Q09)Q/V2KZOVNU9EK12_+Y7&+4^8B)>)+>4\ZZS=F?&,U#_N-%G]^-P'& M%V$S6.9>+^H4#TN\'\O[?>,(C9Q*..4Z:(:Z-OCN)D(O:C:!CKE[V0#=Q]F# MC?7N"LWEEJD]T7Z+]L_7=ZMJ5Z\KI,]6,"D\D=X**:)>)7HIH>&I<8ZQ^R$J M#6,-?,2*_#8<]U\DX3C]/]_L[[6]$128=64GL[#,?AS>,];`UPFE9TGR\*UXK?KO?/1X43Y?] M;8[;:ECW2UFV0,U@#W*F6&8-!SV2*KF?)M%LB2IUN)P/:3I=+W?=V.>'?9GRM2,UU54O(<=7]80'UQK^/D[1I2O$(K>^\5ODBSH'P?O+'$5=-:!LRU,^$ M$CJ%R*,;E]\I6-1WX37%2L.*6,"S#I;3_:Z<3FP'+XG61<':E-7>?UI4$(W^ M)=&ZJ)"L2XA'!XW>,<9>9,$YWO9\_*YVBMB+*#@308&H"27T+>#:\A?/=(+; MC4N=L33*$B)/O/VDKZ72#LQ MV3/EIY%96GVL$E>RF"WKLNL*.\L\1.JW33C,9S>^C0FHA6ZV')*F$KG(#X+< MQ^-V)_)^:E9P$+!=@>R.OL8X7QNI=7#`C%ANYPB^\?@,0TF#Y-D9[& ME;2TN/M$Z#!0I&U$+7)46\I'L;I,8T01^1@^1P&QGH6]0WAN38+IX7R1>+!E MC9O`VASS]U,30^A0RJ=2,&OA9XF-Z@23`TVGY7A52&Q&TT\%8'\H09(0W M!H/:#9>;0K%`J-X4P)0DSZ'6$Q94I,;K8P-0Y"PQ"&YX$(3US0&U\`7?YY`%-'")T%Q5"A_[/O]P/%^ M/K4465HS>D@%%4O$VYN$4N:C65!D6?P>SFS.S400I('YTAB-$T#A7?&!_U)3 M=^0_D&0C+E@1)LPPI/_FXX'[7XI*%U$1XW'B*S6Z%66:Z&/WP7%SW,!+A;D/ M%S((DZ1SVIL5G9VD985*45X#!"H*SW1=@3+IIBMW*;]AL[\/:"-,3?PYJN1& MP%8:?KS>?2D=U*[KSQ7:*+KQS>A:8SA2HH#U.'RY^`*PG?N8?FDT@;BMQ38Y M,P@I'[<\4)&W$*YTQ:;X MVS3/I#,X:K=YR:6OT0&,P>)#2^Z*P>O*Q_T/KB77B M-.*P1`N2E6+FRYZ30@''9>H:29C(^F7RF*RJ)!L*MMN(H)6]H_'^#LYQET5W MI@P%@5S<"D)EPY-1?6>-471^7!20$_:R5R(LPLQL.@ACM4KI@A%/_(LN>B9\ M=KLIPSDLYN/J\#GCM+5YI$N!*](-_B5OAVB+X>#M!C!>)BD4JO*_\-K`!EP' M5QD6CP#1EY<]2*V12O*0RY=380=#G%&7B?2M:YKK?_P-%QSY^#N/\*THCIPD M<))TPA:?D<@([G?3[Y`+.>?GB]+W8#E3QG-<>0FAH7@NT>T!KDK(!4,OH-_4 MV7_`EO">0RP<(7YK=K@B$@Z6)=>/5J#E,LN1>*Q;E$XMO%_2!>"<041_U$^R M?\X?V3B[J("N^<6-/[)*AF6#D/R5O.BP/L22`F%&B%CE@D^C+3,UWUS_0SP^ M#,EEGI;/@\3'8DA&\Z3G:P35KELFK2.[^?S!]^#G214.PJ2\>+Q-["=DS2J=U.>/L.CE^2HJ0AVVPG#7(M9K=CW@*EY*YK#+7W\Z MYC1B_A[+L"]]KXE1G3VSYX`@PR?*M2,`69R`FF%2*M)5?<&&:";D:)$;5$4/YBTCY M"^^T`JF?0VQ&`;.5",]>$]ANGF2;X[D<)9N__3B58W]&H\H]F$ZN(*2-&SF= M%P3+O'@_D3P^G6BO`5E!%!$]".ZN3HMBM9M]RL`-&^^81^_N<\+3-^[R?3'O,$%& MA-3-P^.T/T%/:J)P-#$M[;;/=_U@I:O"[!(N/,ZJ\.-\UD!+A`OW$9?S[9VHH+3S&EGM2=/YH..6 MA/68:_*3-HI&C*:$JR:E@R2&9A%&6ST^A:<>F2A\=OWZ&B3$*6.YM'_\Q_^$ M`8.@SM:+PB2ID]YBJ\;C;'49ZZ?)H;APW&&^6^O;5OKPBY_PE>L[A'4FH@_G M"S`1KFR!D>/!V&(-8N'XCBN$#$:MIZJD+58?)]P5M^G-/*VSN\5"Q%VXR)@K MCEE<>*"%3*,=3EG)6H@SZ@'74DBSZ_WK5'*+.#LL%Y)0IH&T$&+GSZQ4E<8% MJ%J7._NHEP?!F:)RT1U4Z$>$-U8..4H"9\AU0BVKS5]A559-`&T?5;QD08&4 MO>@+/#TQW]I>E(652\I522N)@S,?*.Y$S;6\CYX[1N$$/E2,\0TSJ1V%%SY+ MPARK@(?=-Z2;@RZ`,ZI'4"B*R'[6+5K'P:&PU"C;='-OVE"I9\HM68?.` M,'"B\U>Z*BD*[\FS-:0UFS&4B(.(H>FG+,+8B1%>ZX3EA_R^M*Q!%%,V*Y8X MT8Q'U[&+G_L=NU+]82\]:4$R0\_QG8=.>TN6"CQH(ZI&8%=42?EO__Y__NW? M_PNH+`[C\FVS.VQ$]SQ_SN_Z6@6#420XC8IALUL`;(D,6\`?V:=-,51I]>!( M4J*R_'X>CHL5D[]HM^!TAT'ZT0:2G2?JGM9K4S^(5I>.A:LRH[H"VSD`@]*B M`TT-VXV&W5:W`'F*`)2U*GUF,:A8,(EY*M^'?KD,:CE$$95((E(9>/>),:E$ M"CP.?N4*56.[%BJ=Y8;B3J5;-"I1Y'?89_JC$"24":A0M=;)M^E3:R5K MP=>9-I(<`GM1.&=_>H#%B#+QAI][^(HP)OH@K1RFR(9*9O)?E]/H09,JS''@ M)-TTTO21S=//10EAM;PKZJ=BV9Z&&A-](=$!VQ%A\L7DY!V!*L'F`Q]F\F`I M19JR&I):IC>O8]G57M/*[)[3]/,Z*+/5,K?=&OTXVQ,(-LGJ\7DE_TT2V6O; M`Z"O*426S_HJN$ABC0;$=%L6?T\.JQTU4-$_[1T6?1T^!FSA:6*KG9LPG=AE MB&M,9](X(X(W,!C+=%$1'!I9<^-J;)I:Y8>=@!`8?*WT3&LE(2F-UD^?/29L MP$Q0VU]J`%&R[^MI`1;KET:;>&=RL`5D>2>U1^&X'J%Y^#`UB$"]M1$]:N-2D_;)^5@IO;U#*,%>!K.*IL8E3TC[_PLZE?[$9* M$3DZ1]-^4H?M*`EDLR@0*!(W"T;:0Y#4792`227.[Z0]3$J!%L6W@`Z7VP&\ MWPW![T;XSO,5^TBF!3'1\(=@3V%4-D'?M#6_#*C[('(6A^ME6\L4D;9V*)#" M5MATF70Q8FC5(L(M;?Z:F$@!034]7C_!+L$8EZ2GL4MH1!3)NHE=$:.V7+'. MII,G@)E9I30?JQ1:T2UD159(;1>WX5MV=0RNYC&BI3^?P7&ZJ+MVKI*BLG.& M]J^?WF(QV:M%EC#AU7+\SO94*T485LW`Q+@7[49P[/FU@\&T8C8A]>0B@9J9 M$)\$++^^Y!Y%I20-U.CS(>[QW`2A8UBI8^]P-F:*6HFR\RE`6;/2IY_3A*H" M<,6#8"ETT:Q>&T%"W'BSDWTH1.6P1Y%)(42;_1J6DL$(! M0U]\]C.[*CG:/N5W9#6M\ATD&#H);6P[>+PH%)QHTPC/2HNZX=!(%@2VNF$H M*R^CM M;E=+UV^3/\O@V5\6V7Z+57BPH[W4[Z3#_THJI/I=4LMX>:&(45E*X_'VL,4C M!R_(ZAR.*QA1V_!>X_:D',.`/WPY)&\H27TEVPXQFZZ&H:]V-LUQTZD\U\M4 MZ``7W,+W-PQ?I49\?V6`X0BI.N@7 M>[]C`C:H=OF=%/)BY7HY'J+V@3`K&RW.$FJ4,9$JM!:,0'`P%0OW5<(..#7' MSI7A\&1"4%SK::+U2)Q/&XM.XE=F@1X:1K]YK^L8X1ST[&!1+8+*]-F&M M+L%XK7#.!Y_70>UMQ.M?Y;696YCNY=?RE;]O<=V+^\^SO/C\I&'N@12#A4X@3LM MLB'(5\3^R-?@OUA%T]:,3=DX_TRDNIQM,SQ"D67520$8:LM$'=MML8D`V:G(!%ODFVYN")A-^6U7HYHN=CHLIP%N MTRG?=].E"HA,BP/MXX9?EM].XT):3MDS?>[D_A#MSE`JG M1#%?"=0K/(S_AH"C2/M@6T8X?$;JB0MOH;W6?B(&Y@TSQI M:#6&0IG95\5T0[;W@5F(T"J?X+>8$HGEK/O8VY\G4XQBIB+I3$QA2?O&L6EWA]7-"3*2J4[3"HIN&V?F_I$$8>8 MG[1+LB_C&+8<2^B>/^(L5@0"3M89_X*R&R"JVR*4VOEF@@G M$+7&4$Q8(;^&)4=W@,(2)UDCT\=9?^84N&TP1$*OI'JS>^<,4`38P756SAF!F!&"45KS!8GB`B% MX=0BH::YVP;G3F#3:NYVY2C?;ZYF'`^G$RZH,U*LR>_#F60HOM>I5"J2;L89 J+-\Y+F`O2V&6YW-VI-[\[>]_V__]/_XKMXC_*="?_^/_`:JMN9QG#P$` ` end -- dima From owner-freebsd-hackers Tue Oct 17 21:12:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA23967 for hackers-outgoing; Tue, 17 Oct 1995 21:12:46 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA23962 ; Tue, 17 Oct 1995 21:12:40 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id VAA25960; Tue, 17 Oct 1995 21:12:37 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id VAA28977; Tue, 17 Oct 1995 21:11:33 -0700 Message-Id: <199510180411.VAA28977@corbin.Root.COM> To: dima@freebsd.org (Dima Ruban) cc: freebsd-hackers@freebsd.org Subject: Re: panic In-reply-to: Your message of "Tue, 17 Oct 95 21:01:13 PDT." <199510180401.VAA23373@freefall.freebsd.org> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 17 Oct 1995 21:11:33 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >Does the anybody have an idea, what's going on? ... >panic: brelse: page missing Looks like an old bug that was fixed recently. What are you running? -DG From owner-freebsd-hackers Tue Oct 17 21:33:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA25283 for hackers-outgoing; Tue, 17 Oct 1995 21:33:36 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA25273 ; Tue, 17 Oct 1995 21:33:28 -0700 Received: by sequent.kiae.su id AA26580 (5.65.kiae-2 ); Wed, 18 Oct 1995 08:31:09 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Wed, 18 Oct 95 08:31:08 +0400 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id HAA00330; Wed, 18 Oct 1995 07:30:20 +0300 To: Terry Lambert Cc: core@FreeBSD.ORG, hackers@FreeBSD.ORG, kaleb@x.org, phk@critter.tfs.com, wollman@lcs.mit.edu References: <199510180207.TAA29166@phaeton.artisoft.com> In-Reply-To: <199510180207.TAA29166@phaeton.artisoft.com>; from Terry Lambert at Tue, 17 Oct 1995 19:07:29 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Wed, 18 Oct 1995 07:30:20 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: Locale stuff: call for conclusion. Lines: 64 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2257 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message <199510180207.TAA29166@phaeton.artisoft.com> Terry Lambert writes: >> Well... What is our final decision about XPG4->XPG3 migration? >> Does your words about #define XPG4 means that Garrett >> agrees to #ifdef XPG4 ? >No. He wants localization to take place to XPG/4, if it takes place >at all. >In the runic case of XPG/4, he wants the declaration "doesn't work", >and thus it will poke its head up the first time someone in a runic >locale trys to run an 8 bit clean piece of code that sets locale but >is not capable of handling runes. >My suggestion is: >4) Use #ifdef'ed code to make a seperate XPG/4 library from the > same code that results in an XPG/3 library integrated with the > C library. See below. > Use object module dependencies in the XPG/4 version of the > library to cause it to be completely dragged in place of the > libc XPG/3 code if it is linked before the libc which contains > the XPG/3 code. I believe there is a shared library problem > that this will cause to show up: shared library symbols will > override non-shared library symbols. This has to be fixed. See below. > Add XPG/3 localization to all 8-bit clean code. I plan to do it by adding setlocale(LC_ALL, "") into main() of each 8bit clean program. > Leave all 8-bit unclean code unlocalized. Alternative: cleanup 8bit unclean code. > Use ISO 8859-1 as the C locale. We already agree. I expect some sort of patch from you or Kaleb. > Add a directive to the default .mk files to cause the use of > XPG/4 instead of XPG/3 when the directive is specified. See below. Well, here is *below*. I not fully understand why mess with linker here. My idea is left XPG4 inplace, but restrict it to load only XPG3 valid data for now. In this case it will looks like XPG3 from program point of view, moreover, large part of my hack (XPG3 restrictions) will be removed too automatically. Later we can easily switch to XPG4 by removing those restrictions. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Tue Oct 17 21:35:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA25364 for hackers-outgoing; Tue, 17 Oct 1995 21:35:30 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA25355 for ; Tue, 17 Oct 1995 21:35:20 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id VAA18913; Tue, 17 Oct 1995 21:35:03 -0700 To: Wilson MacGyver cc: hackers@freebsd.org Subject: Re: new Linux for ISP... In-reply-to: Your message of "Tue, 17 Oct 1995 22:36:42 EDT." <199510180236.WAA00198@donna.cylatech.com> Date: Tue, 17 Oct 1995 21:35:03 -0700 Message-ID: <18911.813990903@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > I just saw a book on using Linux for ISP yesterday... I wonder if this > will start making people using Linux for ISP... I guess it depends on how much they're willing to stay ISPs.. :-) Jordan From owner-freebsd-hackers Tue Oct 17 22:10:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA27172 for hackers-outgoing; Tue, 17 Oct 1995 22:10:43 -0700 Received: from rover.village.org (rover.village.org [198.137.146.49]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA27164 for ; Tue, 17 Oct 1995 22:10:39 -0700 Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id XAA16946; Tue, 17 Oct 1995 23:10:05 -0600 Message-Id: <199510180510.XAA16946@rover.village.org> To: jdp@polstra.com (John Polstra) Subject: Re: getdtablesize() broken? Cc: terry@lambert.org, freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of Tue, 17 Oct 1995 15:23:00 PDT Date: Tue, 17 Oct 1995 23:10:03 -0600 From: Warner Losh Sender: owner-hackers@FreeBSD.ORG Precedence: bulk : > In addition, the select(2) call in BSD reserves the right to modify the : > timeval structure to indicate the remaining time to allow the use of : > the timeout as an even outcall mechanism for logical multithreading. : : Yes. I wish more implementations of select actually did that. As someone who ported an application that depended on select(2) not doing that, I can tell you that only Linux will really change the value of timeval in a select call. If that is not correct, I'd like to know who else does change it (rather than merely reserve the right to change it). Warner From owner-freebsd-hackers Tue Oct 17 22:15:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA27348 for hackers-outgoing; Tue, 17 Oct 1995 22:15:06 -0700 Received: from rover.village.org (rover.village.org [198.137.146.49]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA27341 for ; Tue, 17 Oct 1995 22:15:03 -0700 Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id XAA16973 for ; Tue, 17 Oct 1995 23:15:01 -0600 Message-Id: <199510180515.XAA16973@rover.village.org> To: hackers@freebsd.org Subject: Re: new Linux for ISP... In-reply-to: Your message of Wed, 18 Oct 1995 04:08:12 BST Date: Tue, 17 Oct 1995 23:15:00 -0600 From: Warner Losh Sender: owner-hackers@freebsd.org Precedence: bulk There is a lot of talk on the inet-access list about people using Linux as an ISP platform. There are also endless mild flame wars between *bsd and Linux and BSDi vs {Free,Net}BSD. Usually people say Linux tends to get flakey when it gets 100's or routes (or was that 1000's) but FreeBSD is sold when that happens. However, it could be the same person over and over, I haven't paid enough attention to be sure. Also, there are a "fair" number of tia users that run under Linux, and the TIA platform is typically the ISP platform. Warner P.S. (Pardon the plug, but I *always* get questions on TIA when I mention it here: TIA is the internet adapter, it turns shell into IP accounts mostly. More details at http://marketplace.com/) From owner-freebsd-hackers Tue Oct 17 22:20:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA27527 for hackers-outgoing; Tue, 17 Oct 1995 22:20:03 -0700 Received: from peter.cs.andrews.edu (root@peter.cs.andrews.edu [143.207.1.4]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id WAA27522 for ; Tue, 17 Oct 1995 22:20:01 -0700 Received: from edmund (edmund.cs.andrews.edu) by peter.cs.andrews.edu (5.x/SMI-SVR4) id AA10312; Wed, 18 Oct 1995 01:19:57 -0400 From: gillham@andrews.edu (Andrew Gillham) Received: by edmund (5.x) id AA26349; Wed, 18 Oct 1995 01:19:58 -0400 Message-Id: <9510180519.AA26349@edmund> Subject: Re: Stability questions... To: jmb@kryten.atinc.com (Jonathan M. Bresler) Date: Wed, 18 Oct 1995 01:19:08 -0400 (EDT) In-Reply-To: from "Jonathan M. Bresler" at Oct 17, 95 10:14:33 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk > do you have L2 cache set to write-thru or write-back?? write-back. (switched it to -thru just now though) > the board comes withOUT the sram needed to support write-back. > (this sram $123 will gain you 10% speed up on a make world. thanks rod! ;) Per the ASUS FAQ: .Q04) What is the better cache sheme: write-through or write-back ? .How can I upgrade my SP3g with a dirty Tag RAM ? Does it increase .the performance ? From owner-freebsd-hackers Tue Oct 17 22:31:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA28337 for hackers-outgoing; Tue, 17 Oct 1995 22:31:17 -0700 Received: from rover.village.org (rover.village.org [198.137.146.49]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA28325 for ; Tue, 17 Oct 1995 22:31:13 -0700 Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id XAA17046 for ; Tue, 17 Oct 1995 23:31:09 -0600 Message-Id: <199510180531.XAA17046@rover.village.org> To: hackers@freebsd.org Subject: new Linux for ISP Date: Tue, 17 Oct 1995 23:31:09 -0600 From: Warner Losh Sender: owner-hackers@freebsd.org Precedence: bulk In the hopes that they will prove useful, I've run the ratios based on some data we have here. I'd imagine it will tend to reflect the percentage distribution of ISPs, but ISP is losely defined to also include universities... In a random same of users of a certain product, here are the breakdowns for the intel OSes, vs the total: Platform % *BSDi 3.3 FreeBSD 2.3 Linux 5.0 SCO 2.3 *+SYSV 0.8 *Solaris 1.3 Other 85.0 * Intel based only. + Unixware Which is what you'd expect knowing that many ISPs use SunOS, Solaris, Digital Unix, AIIX, Ultrix, IRIX, or HPUX. Those Oses should cover a lot of ground.... So it looks like the Intel market has about a 15% market share of the ISPs and that Linux and *BSD are running neck and neck at about 5% or 6% each, with SCO taking up a little less than 1/2 of the rest. Warner From owner-freebsd-hackers Tue Oct 17 23:19:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA29811 for hackers-outgoing; Tue, 17 Oct 1995 23:19:59 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA29797 for ; Tue, 17 Oct 1995 23:18:45 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA14202; Wed, 18 Oct 1995 16:15:53 +1000 Date: Wed, 18 Oct 1995 16:15:53 +1000 From: Bruce Evans Message-Id: <199510180615.QAA14202@godzilla.zeta.org.au> To: bde@zeta.org.au, matt@lkg.dec.com Subject: Re: IPX now available Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> timeout() is no use if there is nothing to give up control to. >Control will return back to the caller of probe (or attach or ...). >probe could return a meaningful status like EINPROGRESS which would >tell the caller that the probe in continuing. Eventually the driver >(via timeout) will call probe_done() to say the probe finished. For some reason I forgot about you mentioning timeouts and thought you meant something more formal involving lots of driver probe/attach states and entry points in each driver to handle state transitions. This might be good for forcing you to think about synchronization but it would involve modifying too many drivers to begin with. >Let me say upfront that I would love to have kernel threads. But >I'm wary that you are underestinating the amount of work needed to >add them. Properly done kernel thread services are probably the >most significant and useful addition that can be made to FreeBSD. >Can you say SMP? Real pthread support? Better real time support >by thread preemption? I only want toy threads (at first) to allow a common interface in drivers that are called early. You're probably right that I'm underestimating the difficulties. I want interrupts to work normally after they are attached, and few or no probe/attach routines are prepared for interrupts. Bruce From owner-freebsd-hackers Tue Oct 17 23:43:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA01254 for hackers-outgoing; Tue, 17 Oct 1995 23:43:13 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA01238 for ; Tue, 17 Oct 1995 23:43:07 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA15271; Wed, 18 Oct 1995 16:40:12 +1000 Date: Wed, 18 Oct 1995 16:40:12 +1000 From: Bruce Evans Message-Id: <199510180640.QAA15271@godzilla.zeta.org.au> To: freebsd-hackers@FreeBSD.ORG, roberto@keltia.freenix.fr Subject: Re: crt0.c Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >With all the talk about crt0.c, locale and friends, I just saw the >following : >[...] >Why is it using "regular" getenv when it already has its own private one >_getenv ? Because no one noticed that _getenv() existed when the locale bloat was added. The private _getenv() is to avoid linking in whatever bloat may be attached to getenv() (there actually isn't much). Similarly for all the other private functions in crt0.c. Linking to to _startup_selocale() defeats the point of most or all of these because there is a lot of bloat attached to _startup_setlocale(). Bruce From owner-freebsd-hackers Wed Oct 18 00:08:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA02108 for hackers-outgoing; Wed, 18 Oct 1995 00:08:29 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA02101 ; Wed, 18 Oct 1995 00:08:22 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA16305; Wed, 18 Oct 1995 17:04:23 +1000 Date: Wed, 18 Oct 1995 17:04:23 +1000 From: Bruce Evans Message-Id: <199510180704.RAA16305@godzilla.zeta.org.au> To: bakul@netcom.com, terry@lambert.org Subject: Re: getdtablesize() broken? Cc: bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >> > I don't see where this massive amount of runtime work is really worth it. >> >> It is not massive amount of runtime work. Changes are >> fairly straight forward. The runtime cost is small. >> ... >Basically, all of the user space code that uses the standard-since-4.2 >sys/types.h definitions would need to be rewritten. This is what I >meant. The select() interface has pointers to fd_set's, so it doesn't rule out using arrays of fd_set's. I think only the FD_ macros and the documentation would need to be rewritten. >> This is well and good for *user* programs. Most programs don't >> want to bother with changing FD_SETSIZE and kernel changes >> I am proposing are transparent to such programs. >??? >How do I make a program which doesn't guard using FD_SETSIZE the max fd >it tries to select upon suddenly have a larger statically or stack >declared bitvector array? Don't use the standard FD_ macros. Anyway, the kernel needs to handle an arbitrary FD_SETSIZE for compatibility. There is no reason why the Linux FD_SETSIZE should be as limited as the FD_SETSIZE that the kernel happened to be compiled with. Fixed limits defeat binary compatibility. This is particularly annoying for fixed limits like OPEN_MAX that aren't actually fixed even on the host OS. See for a long list of bogus limits. Bruce From owner-freebsd-hackers Wed Oct 18 00:19:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA02432 for hackers-outgoing; Wed, 18 Oct 1995 00:19:11 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA02421 for ; Wed, 18 Oct 1995 00:19:04 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA16864; Wed, 18 Oct 1995 17:14:55 +1000 Date: Wed, 18 Oct 1995 17:14:55 +1000 From: Bruce Evans Message-Id: <199510180714.RAA16864@godzilla.zeta.org.au> To: davidg@root.com, dennis@etinc.com Subject: Re: Shutdown Procedure Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >I noticed that if_ed.c calls ed_registerdev() at the beginning of the probe >routine rather than after if_attach() as in previous releases and as some >other drivers do. I've also noticed that the device is in the table even if >it is disabled. What is the reason for the change? So that devices are registered even if they aren't configured. Perhaps there should be more states to distinguish probed nonexistent devices from probed existent ones and attached devices from unattached ones; currently all probed existent devices are attached so there would be no devices in the new states. >Who/what uses the kdc_state information, and what is the impact of a device >being IDLE or BUSY? Currently, mainly lsdev. Users looking at lsdev output would be confused if the device state is reported incorrectly. Bruce From owner-freebsd-hackers Wed Oct 18 01:27:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA05084 for hackers-outgoing; Wed, 18 Oct 1995 01:27:21 -0700 Received: from MediaCity.com (root@easy1.mediacity.com [205.216.172.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA05076 for ; Wed, 18 Oct 1995 01:27:17 -0700 Received: (from brian@localhost) by MediaCity.com (8.6.11/8.6.9) id BAA03216 for freebsd-hackers@freebsd.org; Wed, 18 Oct 1995 01:29:47 -0700 From: Brian Litzinger Message-Id: <199510180829.BAA03216@MediaCity.com> Subject: device number for watchdog board driver To: freebsd-hackers@freebsd.org Date: Wed, 18 Oct 1995 01:29:47 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Content-Length: 305 Sender: owner-hackers@freebsd.org Precedence: bulk I have a device driver and support programs for the DVI Watchdog Reset board. Shall we get it its own major device number? The driver and support program have a copyright FreeBSD core members will probably be willing to co-habitat with. see http://www.mpress.com Brian Litzinger brian@mediacity.com From owner-freebsd-hackers Wed Oct 18 01:32:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA05316 for hackers-outgoing; Wed, 18 Oct 1995 01:32:37 -0700 Received: from netcom22.netcom.com (bakul@netcom22.netcom.com [192.100.81.136]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA05311 ; Wed, 18 Oct 1995 01:32:36 -0700 Received: from localhost by netcom22.netcom.com (8.6.12/Netcom) id BAA18615; Wed, 18 Oct 1995 01:30:42 -0700 Message-Id: <199510180830.BAA18615@netcom22.netcom.com> To: Bruce Evans , terry@lambert.org Cc: current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? In-reply-to: Your message of "Wed, 18 Oct 95 17:04:23 +1000." <199510180704.RAA16305@godzilla.zeta.org.au> Date: Wed, 18 Oct 95 01:30:40 -0700 From: Bakul Shah Sender: owner-hackers@FreeBSD.org Precedence: bulk Bruce: > The select() interface has pointers to fd_set's, so it doesn't rule out > using arrays of fd_set's. I think only the FD_ macros and the > documentation would need to be rewritten. fd_set is a struct containing just an array of longs. You don't need to make an array of fd_set -- just use a bigger array (big enough to hold the highest valid fd). Me in an earlier message: >> This is well and good for *user* programs. Most programs don't >> want to bother with changing FD_SETSIZE and kernel changes >> I am proposing are transparent to such programs. What I meant is this: If the _kernel_ treats select()'s readfds, writefds, exceptfds as ptrs to int-arrays (and *not* fd_set ptrs), and allocates kernel copies of the same dynamically, this change removes the fixed limit and is transparent to user programs. All old programs using select continue working (for whatever value of FD_SETSIZE provided descriptors limit is high enough). You can even do this and it will work: cc -DFD_SETSIZE=33 foo.c cc -DFD_SETSIZE=333 foo.c You can also use dynamically or statically allocated long- int-arrays instead of fd_set and things will keep working (though lint will complain). Terry responded: >How do I make a program which doesn't guard using FD_SETSIZE the max fd >it tries to select upon suddenly have a larger statically or stack >declared bitvector array? Your program should either use fd_set (and implicitly FD_SETSIZE) or just do dynamic allocation of long-int-arrays to hold the bitvectors. (BTW, gcc will allow you to do dynamic alloc. on the stack). Basically if your program uses fixed size sets, fd_set is fine -- just redefine FD_SETSIZE to what you want. If your program wants to adjust the array size dynamically you are better off using long-int-arrays. But in the latter case you can't use the FD_ macros. What I do in C++ is define a class with methods like add, remove, ismember, members (to return a list of ints corresponding to set bits) etc. You can do something similar in C (but to avoid the overhead you'd've to use macros or inline functions). Bruce again: > Anyway, the kernel needs to handle an arbitrary FD_SETSIZE for > compatibility. There is no reason why the Linux FD_SETSIZE should be as > limited as the FD_SETSIZE that the kernel happened to be compiled with. That is exactly the point I have been trying to make. Thanks! I should've just made the change - would've been quicker!! --bakul From owner-freebsd-hackers Wed Oct 18 01:35:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA05442 for hackers-outgoing; Wed, 18 Oct 1995 01:35:14 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA05327 for ; Wed, 18 Oct 1995 01:32:42 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA14356; Wed, 18 Oct 1995 09:32:30 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA08438; Wed, 18 Oct 1995 09:32:25 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id JAA09280; Wed, 18 Oct 1995 09:08:01 +0100 From: J Wunsch Message-Id: <199510180808.JAA09280@uriah.heep.sax.de> Subject: Re: Pending crisis in packages/All/... To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 18 Oct 1995 09:07:59 +0100 (MET) Cc: hackers@freefall.freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <13671.813938373@time.cdrom.com> from "Jordan K. Hubbard" at Oct 17, 95 06:59:33 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 877 Sender: owner-hackers@FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > mksiofs can't hack it. > > mkisofs breaks badly on a directory containing as many symlinks as the > packages/All directory does, and last time I was not able to get > packages/All on the CDROM because of it. To not be able to do How can i reproduce it? I don't have the IP link to suck all that stuff right now. I've quickly created a directory structure containing 400 zero length files scattered throughout 10 directories, accompanied by symlinks into one "central" directory. mkisofs handled that image fine. Do i have to take longer file names? Non-zero files? I think fixing mkisofs is the most useful solution. All your options are grrr..., so why not use that one? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Oct 18 01:46:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA05815 for hackers-outgoing; Wed, 18 Oct 1995 01:46:38 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id BAA05808 for ; Wed, 18 Oct 1995 01:46:34 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t5U8u-0003wHC; Wed, 18 Oct 95 01:46 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id JAA00192; Wed, 18 Oct 1995 09:46:31 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: Bruce Evans cc: freebsd-hackers@FreeBSD.ORG, roberto@keltia.freenix.fr Subject: Re: crt0.c In-reply-to: Your message of "Wed, 18 Oct 1995 16:40:12 +1000." <199510180640.QAA15271@godzilla.zeta.org.au> Date: Wed, 18 Oct 1995 09:46:30 +0100 Message-ID: <190.814005990@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > >With all the talk about crt0.c, locale and friends, I just saw the > >following : > >[...] > >Why is it using "regular" getenv when it already has its own private one > >_getenv ? > > Because no one noticed that _getenv() existed when the locale bloat was > added. The private _getenv() is to avoid linking in whatever bloat may > be attached to getenv() (there actually isn't much). Similarly for all > the other private functions in crt0.c. Linking to to _startup_selocale() > defeats the point of most or all of these because there is a lot of bloat > attached to _startup_setlocale(). BZZZT!!! Wrong. The local functions, as well as the local syscall code is there so that it works before libc.so has been loaded. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-hackers Wed Oct 18 04:24:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA07057 for hackers-outgoing; Wed, 18 Oct 1995 04:24:34 -0700 Received: from ccsread.dlsu.edu.ph (csread.dlsu.edu.ph [165.220.9.125]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA07023 ; Wed, 18 Oct 1995 04:23:35 -0700 Received: (from humprey@localhost) by ccsread.dlsu.edu.ph (8.6.11/8.6.9) id TAA01894; Wed, 18 Oct 1995 19:21:16 +0800 Date: Wed, 18 Oct 1995 19:21:13 +0800 (HKT) From: "Humprey C. Sy" To: hackers@freebsd.org cc: questions@freebsd.org Subject: lkm programming Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Can anybody point me to some direction where I might get information on implementing loadable kernel modules? - Humprey - From owner-freebsd-hackers Wed Oct 18 05:51:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA00816 for hackers-outgoing; Wed, 18 Oct 1995 05:51:00 -0700 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA00811 for ; Wed, 18 Oct 1995 05:50:57 -0700 Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA07195; Wed, 18 Oct 1995 08:50:20 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Wed, 18 Oct 1995 08:50 EDT Received: from lakes (lakes [192.96.3.39]) by ponds.UUCP (8.6.11/8.6.5) with ESMTP id HAA29515; Wed, 18 Oct 1995 07:59:34 -0400 Received: (from rivers@localhost) by lakes (8.6.11/8.6.9) id IAA06678; Wed, 18 Oct 1995 08:00:00 -0400 Date: Wed, 18 Oct 1995 08:00:00 -0400 From: Thomas David Rivers Message-Id: <199510181200.IAA06678@lakes> To: astral.msk.su!ache@dg-rtp.dg.com, terry@lambert.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Cc: hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, kaleb@x.org Content-Type: text Content-Length: 345 Sender: owner-hackers@FreeBSD.org Precedence: bulk > KOI8 is a peculiar locale in that it doesn't follow the 8859-x rules > like it should. Like EBCDIC, it needs to die in the long term. On ^^^^^^ With IBM pushing so hard on their POSIX complaint (EBCDIC-based) OE/MVS system; I don't think (unfortunately) that EBCDIC will die any time soon... - Dave Rivers - From owner-freebsd-hackers Wed Oct 18 06:15:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA01279 for hackers-outgoing; Wed, 18 Oct 1995 06:15:43 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA01274 for ; Wed, 18 Oct 1995 06:15:41 -0700 Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA02443; Wed, 18 Oct 1995 06:11:48 -0700 Message-ID: <3084FD14.446B9B3D@FreeBSD.org> Date: Wed, 18 Oct 1995 06:11:48 -0700 From: "Jordan K. Hubbard" X-Mailer: Mozilla 2.0b1 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: Joerg Wunsch CC: "Jordan K. Hubbard" , hackers@freefall.freebsd.org Subject: Re: Pending crisis in packages/All/... References: <199510180808.JAA09280@uriah.heep.sax.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk J Wunsch wrote: > How can i reproduce it? > > I don't have the IP link to suck all that stuff right now. I've > quickly created a directory structure containing 400 zero length files > scattered throughout 10 directories, accompanied by symlinks into one > "central" directory. Do you have reasonably interactive response to the U.S.? I've just gone ISDN here now (running 115.2k/ASYNC - bleah), so I can actually have people log into my development machines at home and do useful things. I will set you up with access to a tree that exhibits these problems! > I think fixing mkisofs is the most useful solution. All your options > are grrr..., so why not use that one? If people are willing to pitch in like this, I say yeah - we should go for it! -- Jordan From owner-freebsd-hackers Wed Oct 18 06:21:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA01403 for hackers-outgoing; Wed, 18 Oct 1995 06:21:22 -0700 Received: from chrome.jdl.com (chrome.onramp.net [199.1.166.202]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA01397 for ; Wed, 18 Oct 1995 06:21:19 -0700 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.jdl.com (8.6.11/8.6.9) with SMTP id IAA09420; Wed, 18 Oct 1995 08:20:56 -0500 Message-Id: <199510181320.IAA09420@chrome.jdl.com> X-Authentication-Warning: chrome.jdl.com: Host localhost.jdl.com didn't use HELO protocol To: imp@village.org cc: freebsd-hackers@FreeBSD.ORG Subject: select(2) timeval Clarity-Index: null Reply-To: jdl@chromatic.com Threat-Level: none Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Date: Wed, 18 Oct 1995 08:20:55 -0500 From: Jon Loeliger Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > : > In addition, the select(2) call in BSD reserves the right to modify the > : > timeval structure to indicate the remaining time to allow the use of > : > the timeout as an even outcall mechanism for logical multithreading. > > As someone who ported an application that depended on select(2) not > doing that, I can tell you that only Linux will really change the > value of timeval in a select call. If that is not correct, I'd like > to know who else does change it (rather than merely reserve the right > to change it). As a point of reference, about a year ago, I wrote a time-based delta queue application under AIX. As I recall, it's BSD interface did NOT adjust the timeval in a select() call, and so I ended up having to compensate for it in my code. jdl From owner-freebsd-hackers Wed Oct 18 07:15:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA02387 for hackers-outgoing; Wed, 18 Oct 1995 07:15:27 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA02377 for ; Wed, 18 Oct 1995 07:15:17 -0700 Received: by sovcom.kiae.su id AA05931 (5.65.kiae-1 ); Wed, 18 Oct 1995 17:05:04 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Wed, 18 Oct 95 17:05:04 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id RAA00378; Wed, 18 Oct 1995 17:01:12 +0300 To: Bruce Evans , freebsd-hackers@FreeBSD.ORG, roberto@keltia.freenix.fr References: <199510180640.QAA15271@godzilla.zeta.org.au> In-Reply-To: <199510180640.QAA15271@godzilla.zeta.org.au>; from Bruce Evans at Wed, 18 Oct 1995 16:40:12 +1000 Message-Id: Organization: Olahm Ha-Yetzirah Date: Wed, 18 Oct 1995 17:01:12 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: crt0.c Lines: 20 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 810 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message <199510180640.QAA15271@godzilla.zeta.org.au> Bruce Evans writes: >>With all the talk about crt0.c, locale and friends, I just saw the >>following : >>[...] >>Why is it using "regular" getenv when it already has its own private one >>_getenv ? >Because no one noticed that _getenv() existed when the locale bloat was >added. The private _getenv() is to avoid linking in whatever bloat may I notice. But use standard getenv() becase locale itself immediately calls getenv() many times. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Wed Oct 18 07:27:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA02606 for hackers-outgoing; Wed, 18 Oct 1995 07:27:50 -0700 Received: from chrome.jdl.com (chrome.onramp.net [199.1.166.202]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA02601 for ; Wed, 18 Oct 1995 07:27:46 -0700 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.jdl.com (8.6.11/8.6.9) with SMTP id JAA09753 for ; Wed, 18 Oct 1995 09:27:38 -0500 Message-Id: <199510181427.JAA09753@chrome.jdl.com> X-Authentication-Warning: chrome.jdl.com: Host localhost.jdl.com didn't use HELO protocol To: freebsd-hackers@freebsd.org Subject: DNS question Clarity-Index: null Reply-To: jdl@chromatic.com Threat-Level: none Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Date: Wed, 18 Oct 1995 09:27:38 -0500 From: Jon Loeliger Sender: owner-hackers@freebsd.org Precedence: bulk Hackers, Is there a way to reliably claim to do DNS for anything less than a full Class-C subnet? I only have a 3-bit subnet, and I question my 'Net friendliness if I claim this in my named.boot: directory /etc/namedb cache . named.root primary 0.0.127.IN-ADDR.ARPA localhost.rev primary jdl.com jdl.hosts primary 166.1.199.IN-ADDR.ARPA jdl.rev The point here is that I appear to resolve all of subet 199.1.166.* when I really only can legitimately resolve 199.1.166.[200-207]. Is there some syntax not revealed in the Albitz/Cricket book that means sort-a like: primary 200.166.1.199.IN-ADDR.ARPA/29 jdl.rev Meta-question: Is there a better DNS list to question for this one? Thanks, jdl From owner-freebsd-hackers Wed Oct 18 07:59:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA03444 for hackers-outgoing; Wed, 18 Oct 1995 07:59:13 -0700 Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA03430 for ; Wed, 18 Oct 1995 07:57:57 -0700 Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.11/8.6.9) id QAA23868 for hackers@FreeBSD.ORG; Wed, 18 Oct 1995 16:51:36 +0200 From: John Hay Message-Id: <199510181451.QAA23868@zibbi.mikom.csir.co.za> Subject: IPX feedback request To: hackers@FreeBSD.ORG (FreeBSD-hackers) Date: Wed, 18 Oct 1995 16:51:36 +0200 (SAT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 633 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Hi, I sent my announcement of IPX for the FreeBSD distribution 5 days ago and I haven't received any feedback yet. I know you are all busy and maybe everyone thought someone else will look at it? :-) If I should mail somewhere else please tell me, but according to the handbook -hackers is the place. In case anyone missed my announcement, I placed the file in: ftp.FreeBSD.ORG/pub/FreeBSD/incoming/ipx-fbsd.tgz It supports ipx but not spx. There is diffs for ifconfig and netstat to understand ipx. The only device driver that I changed was if_ed, because that is the one we use here. John -- John Hay -- John.Hay@csir.co.za From owner-freebsd-hackers Wed Oct 18 08:48:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA09695 for hackers-outgoing; Wed, 18 Oct 1995 08:48:09 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA09690 for ; Wed, 18 Oct 1995 08:48:03 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA03304; Thu, 19 Oct 1995 01:47:27 +1000 Date: Thu, 19 Oct 1995 01:47:27 +1000 From: Bruce Evans Message-Id: <199510181547.BAA03304@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@critter.tfs.com Subject: Re: crt0.c Cc: freebsd-hackers@FreeBSD.ORG, roberto@keltia.freenix.fr Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >> Because no one noticed that _getenv() existed when the locale bloat was >> added. The private _getenv() is to avoid linking in whatever bloat may >> be attached to getenv() (there actually isn't much). Similarly for all >> ... >BZZZT!!! Wrong. >The local functions, as well as the local syscall code is there so that >it works before libc.so has been loaded. Oops. But we're talking about bloat in the static case. This is moot now that a separate scrt0.o (compiled without -DDYNAMIC) is used for the static case. Bruce From owner-freebsd-hackers Wed Oct 18 09:05:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA10790 for hackers-outgoing; Wed, 18 Oct 1995 09:05:00 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA10785 for ; Wed, 18 Oct 1995 09:04:57 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t5az8-0003vwC; Wed, 18 Oct 95 09:04 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id RAA00616; Wed, 18 Oct 1995 17:04:59 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: Bruce Evans cc: freebsd-hackers@FreeBSD.ORG, roberto@keltia.freenix.fr Subject: Re: crt0.c In-reply-to: Your message of "Thu, 19 Oct 1995 01:47:27 +1000." <199510181547.BAA03304@godzilla.zeta.org.au> Date: Wed, 18 Oct 1995 17:04:58 +0100 Message-ID: <614.814032298@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > >> Because no one noticed that _getenv() existed when the locale bloat was > >> added. The private _getenv() is to avoid linking in whatever bloat may > >> be attached to getenv() (there actually isn't much). Similarly for all > >> ... > > >BZZZT!!! Wrong. > > >The local functions, as well as the local syscall code is there so that > >it works before libc.so has been loaded. > > Oops. But we're talking about bloat in the static case. This is moot > now that a separate scrt0.o (compiled without -DDYNAMIC) is used for > the static case. Yes, I'm actually running a cleanup version at home, I have just committed the #ifdef DEBUG part of it, but more will come later. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-hackers Wed Oct 18 09:26:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA11268 for hackers-outgoing; Wed, 18 Oct 1995 09:26:43 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA11263 for ; Wed, 18 Oct 1995 09:26:41 -0700 Received: from exalt.x.org by expo.x.org id AA03805; Wed, 18 Oct 95 12:26:09 -0400 Received: from localhost by exalt.x.org id MAA29751; Wed, 18 Oct 1995 12:26:08 -0400 Message-Id: <199510181626.MAA29751@exalt.x.org> To: ache@astral.msk.su Cc: hackers@freefall.FreeBSD.org Subject: Re: xterm dumps core In-Reply-To: Your message of Wed, 18 Oct 1995 16:49:21 EST. Organization: X Consortium Date: Wed, 18 Oct 1995 12:26:07 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk >Why xterm even use locale.alias? I think XFree for FreeBSD builds >for using _system_ locale instead of shipped with X. >I was under impression that XFree was configured to use system >locale instead of its own. Why it even attempts to do something >when system locale present? It is serious bug. Sigh. There is something seriously wrong, but it's not in X. The ANSI/POSIX/ISO locale model is inadequate for describing things like I/O in a graphical user interface. One of the deficiencies is the inability to describe a set of fonts to use for rendering text in an arbitrary locale. Another deficiency is its failure to address input methods, without which keyboard input in Oriental and Arabic languages would be all but impossible. Thus the X locale support is generally used to supplement the system locale; although e.g. on Linux where the system locale support is so weak it's unusable X bypasses the system locale support completely. (It's amazing to me that an OS "developed" by a European should be so deficient in its localization support.) Because OS vendors can't all agree on a single unified naming scheme it is necessary to have a mechanism to map from the various vendor locale names to the corresponding X name. That's all the locale.alias file is for. If you make changes like this without considering how it might affect the things that have dependencies on them, you pretty much get what you deserve. I'm sure you wouldn't make a gratuitous change like moving printf out of libc would you? If you're going to change your locale naming convention then you need to document the change where people can find it and preserve the old names (perhaps with symlinks) long enough that people can find either the changes or the documentation and make the changes necessary in their software to accomodate your changes. -- Kaleb KEITHLEY From owner-freebsd-hackers Wed Oct 18 09:51:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA12042 for hackers-outgoing; Wed, 18 Oct 1995 09:51:53 -0700 Received: from inetgwy.asctmd.com (inetgwy.mitchell.net [198.59.170.33]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA12036 for ; Wed, 18 Oct 1995 09:51:49 -0700 From: supervisor@alb.asctmd.com Received: from alb.asctmd.com (alb.asctmd.com [198.59.170.34]) by inetgwy.asctmd.com (8.6.11/8.6.9) with SMTP id KAA10181 for ; Wed, 18 Oct 1995 10:51:44 -0600 Received: from ALBUQUERQUE-Message_Server by alb.asctmd.com with WordPerfect_Office; Wed, 18 Oct 1995 10:52:45 -0700 Message-Id: X-Mailer: WordPerfect Office 4.0 Date: Wed, 18 Oct 1995 10:49:34 -0700 To: hackers@FreeBSD.ORG, jhay@mikom.csir.co.za Subject: IPX feedback request -Reply Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >>>>>>>>>>>>>>> I sent my announcement of IPX for the FreeBSD distribution 5 days ago and I haven't received any feedback yet. I know you are all busy and maybe everyone thought someone else will look at it? :-) If I should mail somewhere else please tell me, but according to the handbook -hackers is the place. In case anyone missed my announcement, I placed the file in: ftp.FreeBSD.ORG/pub/FreeBSD/incoming/ipx-fbsd.tgz It supports ipx but not spx. There is diffs for ifconfig and netstat to understand ipx. The only device driver that I changed was if_ed, because that is the one we use here. <<<<<<<<<<<<<<< I modified netns for routing usage at the beginning of this year for inclusion in the 2.0-RELEASE source tree. It was a series of patches to be applied for IPX/SPX compatibility in the 2.0 kernel. I uploaded the changes as netipx.tar.z to a couple of archive sites and sent out an announcement as well; don't get discouraged. There just appears to be little interest in performing this kind of function. All of my work on the code patches stopped when there was no feed back. For those that are interested: I can send you a copy of the diffs relative to a 2.0-Release source tree... Mike Mitchell AMTECH Systems Corp 505-856-8000 From owner-freebsd-hackers Wed Oct 18 10:03:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA12306 for hackers-outgoing; Wed, 18 Oct 1995 10:03:00 -0700 Received: from spot.lodgenet.com (lodgenet.iw.net [204.157.148.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA12261 for ; Wed, 18 Oct 1995 10:01:34 -0700 Received: from jake.lodgenet.com (jake.lodgenet.com [204.124.120.30]) by spot.lodgenet.com (8.6.12/8.6.12) with ESMTP id MAA19720 for ; Wed, 18 Oct 1995 12:01:52 -0500 Received: from localhost (localhost [127.0.0.1]) by jake.lodgenet.com (8.6.12/8.6.12) with SMTP id MAA12192 for ; Wed, 18 Oct 1995 12:09:23 -0500 Message-Id: <199510181709.MAA12192@jake.lodgenet.com> X-Authentication-Warning: jake.lodgenet.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: hackers@freebsd.org Subject: apache's knob in /etc/sysconfig Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 12:09:22 -0500 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org Precedence: bulk I just installed 2.1.0-951005-SNAP, and whoever moved appache's httpd from ${PREFIX}/www/server/httpd to ${PREFIX}/sbin/httpd, didn't update /etc/rc to reflect the change. eric. -- erich@lodgenet.com erich@rrnet.com From owner-freebsd-hackers Wed Oct 18 10:21:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA12749 for hackers-outgoing; Wed, 18 Oct 1995 10:21:54 -0700 Received: from spot.lodgenet.com (lodgenet.iw.net [204.157.148.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA12736 for ; Wed, 18 Oct 1995 10:20:28 -0700 Received: from jake.lodgenet.com (jake.lodgenet.com [204.124.120.30]) by spot.lodgenet.com (8.6.12/8.6.12) with ESMTP id MAA19959 for ; Wed, 18 Oct 1995 12:20:42 -0500 Received: from localhost (localhost [127.0.0.1]) by jake.lodgenet.com (8.6.12/8.6.12) with SMTP id MAA12347 for ; Wed, 18 Oct 1995 12:28:13 -0500 Message-Id: <199510181728.MAA12347@jake.lodgenet.com> X-Authentication-Warning: jake.lodgenet.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: hackers@freebsd.org Subject: Device Writer Document Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 12:28:12 -0500 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org Precedence: bulk I've put an updated version of my device driver writer's guide in ~erich/ddwg.sgml on freefall. Could someone who knows drivers please check it out for me. Its not 100% finished, in fact if you include the `kernel support routine' section it's less than half. But the driver part is about 90% done. tia, eric. -- erich@lodgenet.com erich@rrnet.com From owner-freebsd-hackers Wed Oct 18 10:58:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA13381 for hackers-outgoing; Wed, 18 Oct 1995 10:58:25 -0700 Received: from iaehv.IAEhv.nl (root@iaehv.IAEhv.nl [192.87.208.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA13372 for ; Wed, 18 Oct 1995 10:58:16 -0700 Received: from oasis.IAEhv.nl by iaehv.IAEhv.nl (8.6.12/1.63) id SAA04826; Wed, 18 Oct 1995 18:57:57 +0100 X-Disclaimer: iaehv.nl is a public access UNIX system and cannot be held responsible for the opinions of its individual users. Received: by oasis (8.6.12/1.63) id SAA01994; Wed, 18 Oct 1995 18:20:15 +0100 From: volf@oasis.IAEhv.nl (Frank Volf) Message-Id: <199510181720.SAA01994@oasis> Subject: Re: DNS question To: jdl@chromatic.com Date: Wed, 18 Oct 1995 18:20:15 +0100 (MET) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199510181427.JAA09753@chrome.jdl.com> from "Jon Loeliger" at Oct 18, 95 09:27:38 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1939 Sender: owner-hackers@freebsd.org Precedence: bulk Hi, Unfortunately, what you want is impossible. The smallest entity in the DNS is the reverse mapping of a C-net. You must ask the "real" owner of the 166.1.199.IN-ADDR.ARPA zone to add reverse mappings for your IP addresses. Meta-answer: subscribe to the bind mailing list bind-request@uunet.uu.net) Regards, Frank > Hackers, > > Is there a way to reliably claim to do DNS for anything less than > a full Class-C subnet? I only have a 3-bit subnet, and I question > my 'Net friendliness if I claim this in my named.boot: > > directory /etc/namedb > > cache . named.root > primary 0.0.127.IN-ADDR.ARPA localhost.rev > > primary jdl.com jdl.hosts > primary 166.1.199.IN-ADDR.ARPA jdl.rev > > The point here is that I appear to resolve all of subet 199.1.166.* > when I really only can legitimately resolve 199.1.166.[200-207]. > Is there some syntax not revealed in the Albitz/Cricket book that > means sort-a like: > > primary 200.166.1.199.IN-ADDR.ARPA/29 jdl.rev > > Meta-question: Is there a better DNS list to question for this one? > > Thanks, > jdl > ---------------------------------------------------------------------------- Frank Volf - Internet Access Eindhoven - Digitale Stad Eindhoven ---------------------------------------------------------------------------- || volf@oasis.IAEhv.nl - use for personal mail || || volf@IAEhv.nl - use for Internet Access Eindhoven related mail || || volf@dse.dse.nl - use for Digital City of Eindhoven related mail || ---------------------------------------------------------------------------- IAE Public Access Unix System - Dial +31.40.2439436 and login as new. ---------------------------------------------------------------------------- From owner-freebsd-hackers Wed Oct 18 11:42:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA15878 for hackers-outgoing; Wed, 18 Oct 1995 11:42:42 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA15873 for ; Wed, 18 Oct 1995 11:42:40 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id LAA20694; Wed, 18 Oct 1995 11:41:59 -0700 From: Julian Elischer Message-Id: <199510181841.LAA20694@ref.tfs.com> Subject: Re: IPX feedback request -Reply To: supervisor@alb.asctmd.com Date: Wed, 18 Oct 1995 11:41:59 -0700 (PDT) Cc: hackers@FreeBSD.ORG, jhay@mikom.csir.co.za In-Reply-To: from "supervisor@alb.asctmd.com" at Oct 18, 95 10:49:34 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2201 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk I think the first suggestion was closer to the truth.. If you want I will take responsibility for puting these in the source tree.. (I can do both sets if they are compatible..) The only problem is that I don't know much about Novell protocols. Can the two of you make sure your patches don't clash, and are compatible, with each other? If you do I will guarantee that The resulting combined patch will get applied to the tree. This sort of 'falling through the cracks' is something we really have a problem with.. >From My own perspective, I'd say "hey that's great" when I see these patches, but I'd assume someone else will import them because I know nothing about Novell stuff. anyhow, if you two guys can get me patches relative to -current that don't collide. I WILL put them in.. OK? (after checking that they don't break anythign that I DO know about) julian > > >>>>>>>>>>>>>>> > I sent my announcement of IPX for the FreeBSD distribution 5 days ago > and > I haven't received any feedback yet. I know you are all busy and maybe > everyone thought someone else will look at it? :-) > > If I should mail somewhere else please tell me, but according to the > handbook -hackers is the place. > > In case anyone missed my announcement, I placed the file in: > ftp.FreeBSD.ORG/pub/FreeBSD/incoming/ipx-fbsd.tgz > > It supports ipx but not spx. There is diffs for ifconfig and netstat to > understand ipx. The only device driver that I changed was if_ed, > because that is the one we use here. > <<<<<<<<<<<<<<< > I modified netns for routing usage at the beginning of this year for > inclusion in the 2.0-RELEASE source tree. It was a series of patches to > be applied for IPX/SPX compatibility in the 2.0 kernel. > > I uploaded the changes as netipx.tar.z to a couple of archive sites > and sent out an announcement as well; don't get discouraged. There just > appears to be little interest in performing this kind of function. All of my > work on the code patches stopped when there was no feed back. > > For those that are interested: I can send you a copy of the diffs relative > to a 2.0-Release source tree... > > Mike Mitchell > AMTECH Systems Corp > 505-856-8000 > > > From owner-freebsd-hackers Wed Oct 18 11:47:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA16261 for hackers-outgoing; Wed, 18 Oct 1995 11:47:44 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA16252 for ; Wed, 18 Oct 1995 11:47:41 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id LAA20705; Wed, 18 Oct 1995 11:46:25 -0700 From: Julian Elischer Message-Id: <199510181846.LAA20705@ref.tfs.com> Subject: Re: IPX feedback request To: jhay@mikom.csir.co.za (John Hay) Date: Wed, 18 Oct 1995 11:46:25 -0700 (PDT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199510181451.QAA23868@zibbi.mikom.csir.co.za> from "John Hay" at Oct 18, 95 04:51:36 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 854 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Was there any possibility of the changes in the driver being made in if_ethersubr.c rather than the driver itself? julian (p.s. see my other email re: importing this for you) > > Hi, > > I sent my announcement of IPX for the FreeBSD distribution 5 days ago and > I haven't received any feedback yet. I know you are all busy and maybe > everyone thought someone else will look at it? :-) > > If I should mail somewhere else please tell me, but according to the > handbook -hackers is the place. > > In case anyone missed my announcement, I placed the file in: > ftp.FreeBSD.ORG/pub/FreeBSD/incoming/ipx-fbsd.tgz > > It supports ipx but not spx. There is diffs for ifconfig and netstat to > understand ipx. The only device driver that I changed was if_ed, because > that is the one we use here. > > John > -- > John Hay -- John.Hay@csir.co.za > From owner-freebsd-hackers Wed Oct 18 12:04:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA17131 for hackers-outgoing; Wed, 18 Oct 1995 12:04:25 -0700 Received: from kalypso.iqm.unicamp.br (kalypso.iqm.unicamp.br [143.106.13.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA16721 for ; Wed, 18 Oct 1995 11:53:44 -0700 Received: (from vazquez@localhost) by kalypso.iqm.unicamp.br (8.6.11/8.6.9) id QAA13905; Wed, 18 Oct 1995 16:40:49 GMT From: Pedro A M Vazquez Message-Id: <199510181640.QAA13905@kalypso.iqm.unicamp.br> Subject: Re: DNS question To: volf@oasis.IAEhv.nl (Frank Volf) Date: Wed, 18 Oct 1995 16:40:46 +0000 () Cc: jdl@chromatic.com, freebsd-hackers@freebsd.org In-Reply-To: <199510181720.SAA01994@oasis> from "Frank Volf" at Oct 18, 95 06:20:15 pm Organization: Instituto de Quimica Unicamp X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 11179 Sender: owner-hackers@freebsd.org Precedence: bulk Frank Volf said: > > > Hi, > > Unfortunately, what you want is impossible. The smallest entity in > the DNS is the reverse mapping of a C-net. You must ask the "real" > owner of the 166.1.199.IN-ADDR.ARPA zone to add reverse mappings for > your IP addresses. > > Meta-answer: subscribe to the bind mailing list > bind-request@uunet.uu.net) > > Regards, > > Frank > There is a hack to overcome this but all I have about is the doc below, if anyone knows more about please let me know Pedro Network Working Group Havard Eidnes INTERNET-DRAFT SINTEF RUNIT draft-degroot-classless-inaddr-00.txt Geert Jan de Groot RIPE NCC May 1995 Classless in-addr.arpa delegation 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Should this draft end up being published as an RFC, then: This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 2. Introduction This document describes a way to do in-addr.arpa delegation on non- octet boundaries. The proposed method should thus remove one of the objections to do subnetting on non-octet boundaries but perhaps more significantly, make it possible to assign IP address space in smaller chunks than 24-bit prefixes without losing the ability to delegate authority for the corresponding in-addr.arpa mappings. The proposed method is fully compatible with the original DNS lookup mechanisms specified in [1], i.e. there is no need to modify the lookup algorithm used, and there should be no need to modify any software which does DNS lookups either. Eidnes, de Groot Expires 951124 [Page 1] INTERNET-DRAFT Classless in-addr.arpa delegation May 1995 3. Motivation With the proliferation of classless routing technology, it has become feasible to assign address space on non-octet boundaries. In case of a Very Small Organization with only a few hosts, assigning a full 24-bit prefix (what has traditionally been referred to as a ``class C network number'') often leads to inefficient address space utilization. One of the problems encountered when assigning a longer prefix (less address space) is that it seems impossible for such an organization to maintain its own reverse (``in-addr.arpa'') zone autonomously. If the reverse delegation problem is solved, perhaps the most important objection to assignment of longer prefixes to unrelated organizations can be removed. Let us assume we have assigned the address spaces to three different parties as follows: 192.0.2.0/25 to organization A 192.0.2.128/26 to organization B 192.0.2.192/26 to organization C In the classical approach, this would lead to a single zone like this: $ORIGIN 2.0.192.in-addr.arpa. ; 1 PTR host1.A.domain. 2 PTR host2.A.domain. 3 PTR host3.A.domain. ; 129 PTR host1.B.domain. 130 PTR host2.B.domain. 131 PTR host3.B.domain. ; 193 PTR host1.C.domain. 194 PTR host2.C.domain. 195 PTR host3.C.domain. The administration of this zone is problematic. Authority for this zone can only be delegated once, and this usually translates into ``this zone can only be administrated by one organization.'' The other organizations with address space which corresponds to entries in this zone would thus have to depend on another organization for their address to name translation. With the proposed method, this potential problem can be avoided. Eidnes, de Groot Expires 951124 [Page 2] INTERNET-DRAFT Classless in-addr.arpa delegation May 1995 4. Classless in-addr.arpa domain Since a single zone can only be delegated once we need more points to do delegation on to solve the problem above. These extra points of delegation can be introduced by extending the in-addr.arpa tree downwards, e.g. by using the first address in the corresponding address space as the first component in the name for the zones. For the problem described in the motivation section, the corresponding 4 zone files would look something like this (here shown with network masks and network names in the form specified in [2] as well): $ORIGIN 2.0.192.in-addr.arpa. @ IN SOA my-ns.my.domain. hostmaster.my.domain. ( ... ) ;... 0 NS ns.A.domain. 0 NS some.other.name.server. ; 128 NS ns.B.domain. 128 NS some.other.name.server.too. ; 192 NS ns.C.domain 192 NS some.other.third.name.server. ; 1 CNAME 1.0.2.0.192.in-addr.arpa. 2 CNAME 2.0.2.0.192.in-addr.arpa. 3 CNAME 3.0.2.0.192.in-addr.arpa. ; 129 CNAME 129.128.2.0.192.in-addr.arpa. 130 CNAME 130.128.2.0.192.in-addr.arpa. 131 CNAME 131.128.2.0.192.in-addr.arpa. ; 193 CNAME 193.192.2.0.192.in-addr.arpa. 194 CNAME 194.192.2.0.192.in-addr.arpa. 195 CNAME 195.192.2.0.192.in-addr.arpa. $ORIGIN 0.2.0.192.in-addr.arpa. @ IN SOA ns.A.domain. hostmaster.A.domain. ( ... ) @ NS ns.A.domain. @ NS some.other.name.server. @ PTR networkname.A.domain. @ A 255.255.255.128 ; 1 PTR host1.A.domain. 2 PTR host2.A.domain. 3 PTR host3.A.domain. Eidnes, de Groot Expires 951124 [Page 3] INTERNET-DRAFT Classless in-addr.arpa delegation May 1995 $ORIGIN 128.2.0.192.in-addr.arpa. @ IN SOA ns.B.domain. hostmaster.B.domain. ( ... ) @ NS ns.B.domain. @ NS some.other.name.server.too. @ PTR networkname.B.domain. @ A 255.255.255.192 ; 129 PTR host1.B.domain. 130 PTR host2.B.domain. 131 PTR host3.B.domain. $ORIGIN 192.2.0.192.in-addr.arpa. @ IN SOA ns.C.domain. hostmaster.C.domain. ( ... ) @ NS ns.C.domain @ NS some.other.third.name.server. @ PTR networkname.C.domain. @ A 255.255.255.192 ; 193 PTR host1.C.domain. 194 PTR host2.C.domain. 195 PTR host3.C.domain. An obvious alternative to using the first address in the corresponding address space to name the new zones is simply to use some other (non-numeric) name. It is of course also possible to point to an entirely different part of the DNS tree (outside of the in-addr.arpa tree). This approach makes it necessary to install approximately 256 CNAME records in the parent zone more or less permanently for each size-256 chunk split up this way. Some people might view this as ugly; we will not argue that particular point. It is however quite easy to automatically generate the CNAME resource records in the parent zone once and for all, if the way the address space is partitioned is known. The advantage of this approach over the other proposed approaches for dealing with this problem is that there should be no need to modify any already-deployed software. In particular, the lookup mechanism in the DNS does not have to be modified to accommodate this splitting of the responsibility for the IPv4 address to name translation on ``non-dot'' boundaries. This technique has been in use for several years in at least one installation, apparently with no ill effects. Eidnes, de Groot Expires 951124 [Page 4] INTERNET-DRAFT Classless in-addr.arpa delegation May 1995 5. References [1] P. Mockapetris, ``Domain Names - Concepts and Facilities'', RFC1034, ISI, November 1987. [2] P. Mockapetris, ``DNS Encoding of Network Names and Other Types'', RFC1101, ISI, April 1989. 6. Security Considerations Security considerations are not discussed in this memo. 7. Conclusion The suggested scheme gives more flexibility in delegating authority in the in-addr.arpa domain, thus making it possible to assign address space more efficiently without losing the ability to delegate the DNS authority over the corresponding address to name mappings. 8. Acknowledgments Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp-ip.domains some time ago. Alan Barrett , Sam Wilson , and Paul Vixie provided valuable comments on the newsgroup. We would like to thank Eric Wassenaar of NIKHEF , David Kessens , Daniel Karrenberg , Paul Vixie , and Glen A. Herrmannsfeldt for their review and constructive comments. Eidnes, de Groot Expires 951124 [Page 5] INTERNET-DRAFT Classless in-addr.arpa delegation May 1995 9. Author's Addresses Havard Eidnes SINTEF RUNIT N-7034 Trondheim Norway Phone: +73 59 44 68 Fax: +73 59 17 00 Email: Havard.Eidnes@runit.sintef.no Geert Jan de Groot RIPE Network Coordination Centre Kruislaan 409 1098 SJ Amsterdam, the Netherlands Phone: +31 20 592 5065 Fax: +31 20 592 5090 Email: GeertJan.deGroot@ripe.net Eidnes, de Groot Expires 951124 [Page 6] From owner-freebsd-hackers Wed Oct 18 12:12:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA17681 for hackers-outgoing; Wed, 18 Oct 1995 12:12:16 -0700 Received: from spot.lodgenet.com (lodgenet.iw.net [204.157.148.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA17611 for ; Wed, 18 Oct 1995 12:10:53 -0700 Received: from jake.lodgenet.com (jake.lodgenet.com [204.124.120.30]) by spot.lodgenet.com (8.6.12/8.6.12) with ESMTP id OAA20918 for ; Wed, 18 Oct 1995 14:11:03 -0500 Received: from localhost (localhost [127.0.0.1]) by jake.lodgenet.com (8.6.12/8.6.12) with SMTP id OAA13047 for ; Wed, 18 Oct 1995 14:18:34 -0500 Message-Id: <199510181918.OAA13047@jake.lodgenet.com> X-Authentication-Warning: jake.lodgenet.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: hackers@freebsd.org Subject: Re: Device Writer Document In-reply-to: Your message of "Wed, 18 Oct 1995 13:50:42 CDT." <199510181850.NAA29382@miller.cs.uwm.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 14:18:34 -0500 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org Precedence: bulk I have now made a web link to this doc now. as was requested by someone. http://freefall.freebsd.org/~erich/ddwg/ddwg.html eric. -- erich@lodgenet.com erich@rrnet.com From owner-freebsd-hackers Wed Oct 18 12:32:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA18297 for hackers-outgoing; Wed, 18 Oct 1995 12:32:17 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA18288 for ; Wed, 18 Oct 1995 12:32:05 -0700 Received: by sequent.kiae.su id AA25720 (5.65.kiae-2 ); Wed, 18 Oct 1995 23:20:10 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Wed, 18 Oct 95 23:20:09 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id VAA00284; Wed, 18 Oct 1995 21:46:40 +0300 To: "Kaleb S. KEITHLEY" Cc: dawes@rf900.physics.usyd.edu.au, hackers@freefall.FreeBSD.org References: <199510181626.MAA29751@exalt.x.org> In-Reply-To: <199510181626.MAA29751@exalt.x.org>; from "Kaleb S. KEITHLEY" at Wed, 18 Oct 1995 12:26:07 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Wed, 18 Oct 1995 21:46:40 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: xterm dumps core Lines: 46 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2122 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510181626.MAA29751@exalt.x.org> Kaleb S. KEITHLEY writes: >The ANSI/POSIX/ISO locale model is inadequate for describing things >like I/O in a graphical user interface. One of the deficiencies is the >inability to describe a set of fonts to use for rendering text in an >arbitrary locale. Another deficiency is its failure to address input >methods, without which keyboard input in Oriental and Arabic languages >would be all but impossible. Well, I understand. >Because OS vendors can't all agree on a single unified naming scheme >it is necessary to have a mechanism to map from the various vendor locale >names to the corresponding X name. That's all the locale.alias file is >for. So, it is definitely bug in locale.alias, it can't parse valid character sets names which conforms RFC 1700. >If you make changes like this without considering how it might affect >the things that have dependencies on them, you pretty much get what you >deserve. I'm sure you wouldn't make a gratuitous change like moving >printf out of libc would you? I simple follow existen standard for character set names, namely RFC 1700. If X violates RFC 1700 (claiming itself as Standards Body :-) sorry, can't resist) I don't think that it will be good to follow its way only because it is X. >If you're going to change your locale naming convention then you need >to document the change where people can find it and preserve the old >names (perhaps with symlinks) long enough that people can find either >the changes or the documentation and make the changes necessary in >their software to accomodate your changes. Now I plan to patch locale.alias in XFree86 port (by adding RFC 1700 names) and expect that X Consortium take care of RFC 1700 in future. Could you please pass this issue to X development team? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Wed Oct 18 12:37:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA18470 for hackers-outgoing; Wed, 18 Oct 1995 12:37:28 -0700 Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA18465 for ; Wed, 18 Oct 1995 12:37:15 -0700 Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.11/8.6.9) id VAA24643; Wed, 18 Oct 1995 21:33:59 +0200 From: John Hay Message-Id: <199510181933.VAA24643@zibbi.mikom.csir.co.za> Subject: Re: IPX feedback request To: julian@ref.tfs.com (Julian Elischer) Date: Wed, 18 Oct 1995 21:33:59 +0200 (SAT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199510181846.LAA20705@ref.tfs.com> from "Julian Elischer" at Oct 18, 95 11:46:25 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1266 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Most is done in if_ethersubr.c, but the ioctl SIOCSIFADDR is done inside the device driver itself. The file I mentioned below has got diffs for current of about friday. So there should not be trouble with that. If you have any questions please mail me. John -- John Hay -- John.Hay@csir.co.za > > Was there any possibility of the changes in the driver being > made in if_ethersubr.c rather than the driver itself? > > julian > (p.s. see my other email re: importing this for you) > > > > Hi, > > > > I sent my announcement of IPX for the FreeBSD distribution 5 days ago and > > I haven't received any feedback yet. I know you are all busy and maybe > > everyone thought someone else will look at it? :-) > > > > If I should mail somewhere else please tell me, but according to the > > handbook -hackers is the place. > > > > In case anyone missed my announcement, I placed the file in: > > ftp.FreeBSD.ORG/pub/FreeBSD/incoming/ipx-fbsd.tgz ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > It supports ipx but not spx. There is diffs for ifconfig and netstat to > > understand ipx. The only device driver that I changed was if_ed, because > > that is the one we use here. > > > > John > > -- > > John Hay -- John.Hay@csir.co.za > > > > From owner-freebsd-hackers Wed Oct 18 12:50:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA18847 for hackers-outgoing; Wed, 18 Oct 1995 12:50:16 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA18842 ; Wed, 18 Oct 1995 12:50:10 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA00690; Wed, 18 Oct 1995 12:39:49 -0700 From: Terry Lambert Message-Id: <199510181939.MAA00690@phaeton.artisoft.com> Subject: Re: getdtablesize() broken? To: bde@zeta.org.au (Bruce Evans) Date: Wed, 18 Oct 1995 12:39:49 -0700 (MST) Cc: bakul@netcom.com, terry@lambert.org, bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org In-Reply-To: <199510180704.RAA16305@godzilla.zeta.org.au> from "Bruce Evans" at Oct 18, 95 05:04:23 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6382 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >Basically, all of the user space code that uses the standard-since-4.2 > >sys/types.h definitions would need to be rewritten. This is what I > >meant. > > The select() interface has pointers to fd_set's, so it doesn't rule out > using arrays of fd_set's. I think only the FD_ macros and the > documentation would need to be rewritten. OK, I might buy this, though it seems a non-standard way of dealing with the issue. I think the current bit macros would require modification to take address operands, or cast them to long arracys and linearly traverse them in any case. Still, a passed "maxfd" in excess of the array max could have the kernel twiddling the the contents of non-select bit data areas. I think there is no way short of an interface change to cause the user to not have to supply a maxfd <= the actual array length limits, even if you make the kernel not care by breaking the FD_SETSIZE "agreement" between the kernel and the user programs. > >How do I make a program which doesn't guard using FD_SETSIZE the max fd > >it tries to select upon suddenly have a larger statically or stack > >declared bitvector array? > > Don't use the standard FD_ macros. Can't do it without mandating code modifications. If we start down this road, I demand we get rid of tty interfaces other than POSIX termios and just mandate that everyone change their code. Welcome to Plan 9. > Anyway, the kernel needs to handle an arbitrary FD_SETSIZE for > compatibility. There is no reason why the Linux FD_SETSIZE should be as > limited as the FD_SETSIZE that the kernel happened to be compiled with. > Fixed limits defeat binary compatibility. This is particularly annoying > for fixed limits like OPEN_MAX that aren't actually fixed even on the > host OS. See for a long list of bogus limits. ??? Let's see: ] #define ARG_MAX 65536 /* max bytes for an exec function */ Type: Bogus. Required by: The process environment being in the user's address space instead of attached to the proc structure and accessed through system calls. Reason: Support of legacy code that directly manipulates the enviroment in violation of the documented interface, preventing those interfaces from moving from section 3 (library) to section 2 (system calls). ] #define CHILD_MAX 40 /* max simultaneous processes */ Type: Administrative (compile time override) Required by: The ability for a user program to fork(2) the system to death. Reason: There exist intentionally and unintentionally disruptive users. ] #define LINK_MAX 32767 /* max file link count */ Type: Pragmatic Required by: There are limitations on the largest number that can be stored in the "link count" field of an on disk inode. Reason: You can't overcome all design limitations and still have reasonable usability. This is one such limit, which is orders of magnitude larger than the highest "reasonable" value. ] #define MAX_CANON 255 /* max bytes in term canon input line */ Type: Bogus Required by: Seperate cannonization buffer. Reason: No one has double-staged tty input for cannonization to cause it to use a queue based buffering mechanism. ] #define MAX_INPUT 255 /* max bytes in terminal input */ Type: Bogus Required by: Seperate cannonization buffer. Reason: No one has double-staged tty input to cause it to use a queue based buffering mechanism. ] #define NAME_MAX 255 /* max bytes in a file name */ Type: Standard Required by: POSIX compliance Reason: The file component name length limit is mandated to be set to 255 characters. ] #define NGROUPS_MAX 16 /* max supplemental group id's */ Type: Standard (Interoperability, Legacy) Required by: NFS, YP Reason: Excess groups are truncated by the NFS external ID representation mechanism. In point of fact, this limit should be 8 to ensure interoperability with older SVR3/SVR4 systems. ] #define OPEN_MAX 64 /* max open files per process */ Type: Bogus Required by: Bash, tcsh Reason: Stupid programmers of shells attempt to split the open file descriptor numeric name space into two components, and to use the upper component to ensure that a collision with the fd for the currently executing script is not stepped on by the script itself. The correct procedure for systems with memory limited open file limits (AIX, BSD, etc.) is to write the programs to use collision detection and move the script fd, using indirect instead of direct reference to the script fd to allow this. The limit also works around a bug in BSD, which is that the open file limit should be bound by a free memory threshold (as should all allocations initiated as a result of a user request) instead of causing a system panic. ] #define PATH_MAX 1024 /* max bytes in pathname */ Type: Standard Required by: POSIX compliance Reason: The path length limit is mandated to be set to 1024 characters. There is in fact a bug in non-terminal symbolic link expansion in vfs_lookup.c that reduces this limit below the mandated 1024 by using coroutine based mutual recursion to avoid increasing stack depth. This is a programatic error, and is thus only tangentially related to this limit. ] #define PIPE_BUF 512 /* max bytes for atomic pipe writes */ Type: Bogus Required by: Implementation Reason: Buffer atomicity is related to the underlying POSIX domain socket based implementation of pipes. This is in fact a limit which must be traded against pipe depth, and is a conceptual limitation on the idea of pipes. ] #define BC_BASE_MAX 99 /* max ibase/obase values in bc(1) */ ] #define BC_DIM_MAX 2048 /* max array elements in bc(1) */ ] #define BC_SCALE_MAX 99 /* max scale value in bc(1) */ ] #define BC_STRING_MAX 1000 /* max const string length in bc(1) */ ] #define COLL_WEIGHTS_MAX 0 /* max weights for order keyword */ ] #define EXPR_NEST_MAX 32 /* max expressions nested in expr(1) */ ] #define LINE_MAX 2048 /* max bytes in an input line */ ] #define RE_DUP_MAX 255 /* max RE's in interval notation */ Type: Bogus Required by: A user space program Reason: The programmer didn't know he could use "" to delimit include files instead of <>? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Oct 18 12:53:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA18980 for hackers-outgoing; Wed, 18 Oct 1995 12:53:27 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA18975 for ; Wed, 18 Oct 1995 12:53:25 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id MAA20869; Wed, 18 Oct 1995 12:52:56 -0700 From: Julian Elischer Message-Id: <199510181952.MAA20869@ref.tfs.com> Subject: Re: Device Writer Document To: erich@lodgenet.com (Eric L. Hernes) Date: Wed, 18 Oct 1995 12:52:55 -0700 (PDT) Cc: hackers@freebsd.org In-Reply-To: <199510181918.OAA13047@jake.lodgenet.com> from "Eric L. Hernes" at Oct 18, 95 02:18:34 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 579 Sender: owner-hackers@freebsd.org Precedence: bulk looks good. I'll have lots of things to add to this but now I at least know where to add them to the structure is a little confusing.. there seems to be two ways of getting to each page probably the toplevel page shouldn't bypass the next level down.. it should only reference the next layer rather than having direct links.. OR the next layer down shouldn't exist.. > > > I have now made a web link to this doc now. > as was requested by someone. > > http://freefall.freebsd.org/~erich/ddwg/ddwg.html > > > eric. > > -- > erich@lodgenet.com > erich@rrnet.com > > From owner-freebsd-hackers Wed Oct 18 13:01:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA19405 for hackers-outgoing; Wed, 18 Oct 1995 13:01:41 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA19376 ; Wed, 18 Oct 1995 13:01:23 -0700 Received: by sequent.kiae.su id AA01210 (5.65.kiae-2 ); Wed, 18 Oct 1995 23:45:54 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Wed, 18 Oct 95 23:45:52 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id WAA00640; Wed, 18 Oct 1995 22:45:02 +0300 To: dawes@freebsd.org, hackers@freebsd.org, kaleb@x.org Message-Id: Organization: Olahm Ha-Yetzirah Date: Wed, 18 Oct 1995 22:45:02 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Well, I have proper name & X locale installed, why xterm still dumps core? Lines: 14 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 584 Sender: owner-hackers@freebsd.org Precedence: bulk I mean that I have KOI8-R locale installed, i.e. this name present in locale.dir, koi8-r/XLC_LOCALE, tbl_data/tabkoi8-r and koi8-r fonts are installed. xterm still dumps core for me. Why? Dawes, I already sent you related materials, so you can test them on your own machine, please help. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Wed Oct 18 13:07:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA19646 for hackers-outgoing; Wed, 18 Oct 1995 13:07:27 -0700 Received: from spot.lodgenet.com (lodgenet.iw.net [204.157.148.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA19617 for ; Wed, 18 Oct 1995 13:06:00 -0700 Received: from jake.lodgenet.com (jake.lodgenet.com [204.124.120.30]) by spot.lodgenet.com (8.6.12/8.6.12) with ESMTP id PAA21167; Wed, 18 Oct 1995 15:06:16 -0500 Received: from localhost (localhost [127.0.0.1]) by jake.lodgenet.com (8.6.12/8.6.12) with SMTP id PAA13897; Wed, 18 Oct 1995 15:13:47 -0500 Message-Id: <199510182013.PAA13897@jake.lodgenet.com> X-Authentication-Warning: jake.lodgenet.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Julian Elischer Cc: hackers@freebsd.org Subject: Re: Device Writer Document In-reply-to: Your message of "Wed, 18 Oct 1995 12:52:55 PDT." <199510181952.MAA20869@ref.tfs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 15:13:47 -0500 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org Precedence: bulk > looks good. > I'll have lots of things to add to this but now I at least know where to > add them to Glad to hear it.. I was kind of hoping that this would light a fire under the more knowledgeable people to contribute to this. There will be lots of changes when devfs is implemented... > > the structure is a little confusing.. > there seems to be two ways of getting to each page > > probably the toplevel page shouldn't bypass the next level down.. > it should only reference the next layer rather than having direct links.. > OR the next layer down shouldn't exist.. > It's written in straight sgml so the html part is auto-generated. That's kind of a problem with the way the filter works. It plagues the FreeBSD handbook too. :( eric. -- erich@lodgenet.com erich@rrnet.com From owner-freebsd-hackers Wed Oct 18 13:35:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA20713 for hackers-outgoing; Wed, 18 Oct 1995 13:35:17 -0700 Received: from gaia.coppe.ufrj.br (root@gaia.coppe.ufrj.br [146.164.63.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA20631 for ; Wed, 18 Oct 1995 13:34:16 -0700 Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.6.11/8.6.9) id SAA19360; Wed, 18 Oct 1995 18:32:46 -0200 From: Joao Carlos Mendes Luis Message-Id: <199510182032.SAA19360@gaia.coppe.ufrj.br> Subject: Re: IPX feedback request -Reply To: supervisor@alb.asctmd.com Date: Wed, 18 Oct 1995 18:32:45 -0200 (EDT) Cc: hackers@freebsd.org, jhay@mikom.csir.co.za In-Reply-To: from "supervisor@alb.asctmd.com" at Oct 18, 95 10:49:34 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 978 Sender: owner-hackers@freebsd.org Precedence: bulk Hi all, Could any good soul please explain me what can I do with the IPX/SPX support in the kernel ? Is there anything in mind right now ? I can just think of the following: 1) Routing Netware networks. This should be made by a daemon with suport for SAP also. Maybe, NLSP, which is turning to be the recommended routing option. 2) Mounting NetWare disks. This is really a problem. How to convert unix users to netware users ? Should one mount with just one netware user and show unix users all files as root owned ? The other option would be to use one IPX socket for EACH unix user, and would require a much more complex daemon/kernel. 3) Print Services. A netware aware lpd would be useful. Most important: Should be one which could print from Unix to Netware AND vice-versa. Jonny -- Joao Carlos Mendes Luis jonny@coe.ufrj.br +55 21 290-4698 ( Job ) jonny@adc.coppe.ufrj.br Network Manager UFRJ/COPPE/CISI Universidade Federal do Rio de Janeiro From owner-freebsd-hackers Wed Oct 18 13:46:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA21129 for hackers-outgoing; Wed, 18 Oct 1995 13:46:27 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA21117 for ; Wed, 18 Oct 1995 13:46:14 -0700 Received: by sequent.kiae.su id AA23653 (5.65.kiae-2 ); Thu, 19 Oct 1995 00:42:02 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 19 Oct 95 00:42:01 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id XAA00804; Wed, 18 Oct 1995 23:41:36 +0300 To: "Kaleb S. KEITHLEY" Cc: dawes@rf900.physics.usyd.edu.au, hackers@freefall.FreeBSD.org References: <199510181626.MAA29751@exalt.x.org> In-Reply-To: ; from =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= at Wed, 18 Oct 1995 21:46:40 +0300 (MSK) Message-Id: Organization: Olahm Ha-Yetzirah Date: Wed, 18 Oct 1995 23:41:36 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: xterm dumps core Lines: 29 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1301 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= writes: >>If you make changes like this without considering how it might affect >>the things that have dependencies on them, you pretty much get what you >>deserve. I'm sure you wouldn't make a gratuitous change like moving >>printf out of libc would you? >I simple follow existen standard for character set names, namely >RFC 1700. If X violates RFC 1700 (claiming itself as Standards Body :-) >sorry, can't resist) I don't think that it will be good to follow its >way only because it is X. BTW, RFC 1700 not invent those names by itself, but pick them from already existent standard, i.e. ISO in this case. So, name ISO8859-1 is invalid per both ISO and RFC 1700, shure, no such name exist in ISO. For existen 8859 names check ISO or RFC 1700. ISO_8859-1 is one of existen names. I don't plan provide backward compatible links, becase it allows users to use completely non-standard locale names. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Wed Oct 18 13:51:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA21379 for hackers-outgoing; Wed, 18 Oct 1995 13:51:09 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA21314 for ; Wed, 18 Oct 1995 13:49:52 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id VAA15706 ; Wed, 18 Oct 1995 21:46:11 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id VAA06220 ; Wed, 18 Oct 1995 21:46:10 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id VAA08949; Wed, 18 Oct 1995 21:43:06 +0100 (MET) From: Ollivier Robert Message-Id: <199510182043.VAA08949@keltia.freenix.fr> Subject: Re: DNS question To: jdl@chromatic.com Date: Wed, 18 Oct 1995 21:43:05 +0100 (MET) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199510181427.JAA09753@chrome.jdl.com> from "Jon Loeliger" at Oct 18, 95 09:27:38 am X-Operating-System: FreeBSD 2.2-CURRENT ctm#1215 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk It seems that Jon Loeliger said: > Is there a way to reliably claim to do DNS for anything less than > a full Class-C subnet? I only have a 3-bit subnet, and I question > my 'Net friendliness if I claim this in my named.boot: Yes but it is a hack that generates more traffic... to delegate subnets you have to have as many zones as there is address in the subnet. DNS is not really made for anything than A,B,C addresses... > Meta-question: Is there a better DNS list to question for this one? info.bind (in News gatewayed as bind@uunet.uu.net) and comp.protocols.tcp-ip.domains come to mind. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #0: Sat Oct 14 19:05:10 MET 1995 From owner-freebsd-hackers Wed Oct 18 13:52:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA21473 for hackers-outgoing; Wed, 18 Oct 1995 13:52:25 -0700 Received: from chrome.jdl.com (chrome.onramp.net [199.1.166.202]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA21468 ; Wed, 18 Oct 1995 13:52:22 -0700 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.jdl.com (8.6.11/8.6.9) with SMTP id PAA11470; Wed, 18 Oct 1995 15:51:02 -0500 Message-Id: <199510182051.PAA11470@chrome.jdl.com> X-Authentication-Warning: chrome.jdl.com: Host localhost.jdl.com didn't use HELO protocol To: Terry Lambert cc: bde@zeta.org.au (Bruce Evans), bakul@netcom.com, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? In-reply-to: Your message of "Wed, 18 Oct 1995 12:39:49 PDT." <199510181939.MAA00690@phaeton.artisoft.com> Reply-To: jdl@chromatic.com Clarity-Index: null Threat-Level: none Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Date: Wed, 18 Oct 1995 15:51:02 -0500 From: Jon Loeliger Sender: owner-hackers@FreeBSD.org Precedence: bulk Apparently, Terry Lambert scribbled: > > The select() interface has pointers to fd_set's, so it doesn't rule out > > using arrays of fd_set's. I think only the FD_ macros and the > > documentation would need to be rewritten. > > OK, I might buy this, though it seems a non-standard way of dealing with > the issue. I think the current bit macros would require modification to > take address operands, or cast them to long arracys and linearly traverse > them in any case. > > Still, a passed "maxfd" in excess of the array max could have the kernel > twiddling the the contents of non-select bit data areas. > > I think there is no way short of an interface change to cause the user > to not have to supply a maxfd <= the actual array length limits, even > if you make the kernel not care by breaking the FD_SETSIZE "agreement" > between the kernel and the user programs. Yea, and one further silly data point, that may or may not be even vaguely interesting: In AIX land, there were message queues too and they needed the ability to be select()-able as well. You couldn't reliably have a second interface that only looked at msgques, as you could only have one point of "hang" and it had to check for all the possible select() conditions. This led to the fd sets really having a message queue portion just after the set of FD bits. Naturally, in order to find where the first msg que bits were, the length of the fd sets had to be known. When msg queues were needed in the application, this had the further interesting silly effect of not really being able to tell the select() the honest number of "bits that are interesting" while doing the select(). One had to lie and claim the maximum, even though the user could be tracking the largest open fd and know full well that it was much less than the maximum FD. Icky and slow. jdl From owner-freebsd-hackers Wed Oct 18 13:52:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA21540 for hackers-outgoing; Wed, 18 Oct 1995 13:52:55 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA21535 ; Wed, 18 Oct 1995 13:52:51 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA00860; Wed, 18 Oct 1995 13:46:37 -0700 From: Terry Lambert Message-Id: <199510182046.NAA00860@phaeton.artisoft.com> Subject: Re: Locale stuff: call for conclusion. To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Wed, 18 Oct 1995 13:46:37 -0700 (MST) Cc: terry@lambert.org, core@FreeBSD.ORG, hackers@FreeBSD.ORG, kaleb@x.org, phk@critter.tfs.com, wollman@lcs.mit.edu In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 18, 95 07:30:20 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5723 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > Leave all 8-bit unclean code unlocalized. > > Alternative: cleanup 8bit unclean code. Garrett's alternative: cleaunup non-XPG/4 localized code. They sound equally valid when you say them this way, don't they? The problem with making an arbitrary cutoff that prevents gradual migration in one case (XPG/3->XPG/4) but not another (8-bit->XPG/3) is that it is arbitrary where you put the line. Garret's placement and your placement of that line can't be judged to be better or worse than each other, because both are equally arbitrary. You wish to compromise gradual migration of 7->8-bit because there is very little work to go from 8-bit->base-level-XPG/3, and because it benefits you personally to make the requirement that code be 8-bit clean. Garrett's intended requirement that code be XPG/4 localized or that it not call setlocale() destroys gradual migration from any code to XPG/4 localization, but benefits all users of the code (eventually). Garrett's proposal, which would be hard on the existing users of the ctr0.o hack (the poor man's XPG/3), would result in an all-or-nothing choice. But it has a high degree of intellectual honesty. My proposal would allow 7bit code to act unlocalized, and potentially broken when using the locale-specific features of ctype.h and/or when operating on 8bit data (little change from the status quo, since the use of the ctype functions instead of code-based tests is a partial attempt at 8-bit cleanliness). It would allow 8-bit clean code to be loaclized using XPG/3, which would exclude rune-using locales and thus cause code to fail in an expected manner in those locales, instead of unexpectedly/strangely. It would allow the gradual introduction of XPG/4 localization. This has the same degree of intellectual honesty as Garrett's proposal, since it also does not play favorites, with the possible exception of some 7bit programs that failed in international locales failing in a different manner. Since both failure modes were unexpected behaviour to the 8-bit or runic locale residents, I believe this to be acceptable: a strange failure is a strange failure, no matter where it originates, and there is no validity to the argument that one kind of strange is superior to another. The tradeoff between my and Garrett's proposals is that mine drastically reduces the incentive to make code work outside your own locale, while Garrett's risks alienating a large existing user base in order to make the incentive as high as possible. In this way, both are bad; the question is which is "acceptably bad". > > Use ISO 8859-1 as the C locale. > > We already agree. I expect some sort of patch from you or Kaleb. Copy the 8859-1 US locale. No real patch is needed. > > Add a directive to the default .mk files to cause the use of > > XPG/4 instead of XPG/3 when the directive is specified. > > See below. > > Well, here is *below*. > > I not fully understand why mess with linker here. My idea is left > XPG4 inplace, but restrict it to load only XPG3 valid data for now. > In this case it will looks like XPG3 from program point of view, > moreover, large part of my hack (XPG3 restrictions) will be removed too > automatically. > Later we can easily switch to XPG4 by removing those restrictions. This is what we physicists call "hand waving". 8-). This puts another all-or-nothing-choice on the users, bringing your total to two: ,---------------.------------------.------------------.---------------. | Conversion | Garret | Ache | Terry | |---------------+------------------+------------------+---------------| | 7bit | No effect | No effect | No effect | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7->8-bit | | | | | Some 8859-x | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v | v | | 8-bit->XPG/3 | | | i18n function | i18n function | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v | v | v | | XPG/3->XPG/4 | Full function | Full function | Full function | `---------------'------------------'------------------'---------------' The ability to link XPG/3 by default and XPG/4 by option is required to support the optional rather than the "all or nothing" transition between "i18n function" and "full function". The reason to "mess with the linker" is so that XPG/4 binaries are not required to be statically linked and we are not required to maintain a full seperate C library, only an XPG/4 library. Otherwise XPG/4 internationalization is second class twice: once because of the effort to go XPG/3->XPG/4, and once because of the link differences and (potentially) the larger static binary. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Oct 18 13:59:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA21745 for hackers-outgoing; Wed, 18 Oct 1995 13:59:31 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA21738 for ; Wed, 18 Oct 1995 13:59:24 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA00900; Wed, 18 Oct 1995 13:53:16 -0700 From: Terry Lambert Message-Id: <199510182053.NAA00900@phaeton.artisoft.com> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP To: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) Date: Wed, 18 Oct 1995 13:53:16 -0700 (MST) Cc: ache@astral.msk.su, terry@lambert.org, hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, kaleb@x.org In-Reply-To: <199510181200.IAA06678@lakes> from "Thomas David Rivers" at Oct 18, 95 08:00:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 545 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > KOI8 is a peculiar locale in that it doesn't follow the 8859-x rules > > like it should. Like EBCDIC, it needs to die in the long term. On > ^^^^^^ > > With IBM pushing so hard on their POSIX complaint (EBCDIC-based) > OE/MVS system; I don't think (unfortunately) that EBCDIC will die any time > soon... That's the unfortunate difference between "needs" and "will". 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Oct 18 13:59:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA21794 for hackers-outgoing; Wed, 18 Oct 1995 13:59:46 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA21774 for ; Wed, 18 Oct 1995 13:59:40 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA00890; Wed, 18 Oct 1995 13:52:15 -0700 From: Terry Lambert Message-Id: <199510182052.NAA00890@phaeton.artisoft.com> Subject: Re: device number for watchdog board driver To: brian@MediaCity.com (Brian Litzinger) Date: Wed, 18 Oct 1995 13:52:14 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199510180829.BAA03216@MediaCity.com> from "Brian Litzinger" at Oct 18, 95 01:29:47 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 520 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > I have a device driver and support programs for the DVI Watchdog > Reset board. > > Shall we get it its own major device number? > > The driver and support program have a copyright FreeBSD core > members will probably be willing to co-habitat with. Contact Julian Elisher for documentation on the devfs device export interface. Device numbers should no longer be assigned. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Oct 18 14:01:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA21889 for hackers-outgoing; Wed, 18 Oct 1995 14:01:21 -0700 Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA21884 for ; Wed, 18 Oct 1995 14:01:06 -0700 Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.11/8.6.9) id WAA24823; Wed, 18 Oct 1995 22:59:21 +0200 From: John Hay Message-Id: <199510182059.WAA24823@zibbi.mikom.csir.co.za> Subject: Re: IPX feedback request -Reply To: jonny@gaia.coppe.ufrj.br (Joao Carlos Mendes Luis) Date: Wed, 18 Oct 1995 22:59:21 +0200 (SAT) Cc: hackers@freebsd.org In-Reply-To: <199510182032.SAA19360@gaia.coppe.ufrj.br> from "Joao Carlos Mendes Luis" at Oct 18, 95 06:32:45 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1166 Sender: owner-hackers@freebsd.org Precedence: bulk Well IPX/SPX in the kernel will give you the ability to write or port user level programs that need IPX and route packets if some daemon sets the routes. My IPX code do have a daemon that do the RIP and SAP stuff. I havn't got NLSP support. (And am not planning to in the near future.) John -- John Hay -- John.Hay@csir.co.za > > Hi all, > > Could any good soul please explain me what can I do with the IPX/SPX > support in the kernel ? Is there anything in mind right now ? > > I can just think of the following: > > 1) Routing Netware networks. This should be made by a daemon > with suport for SAP also. Maybe, NLSP, which is turning to be > the recommended routing option. > > 2) Mounting NetWare disks. This is really a problem. How to convert > unix users to netware users ? Should one mount with just one netware > user and show unix users all files as root owned ? The other option > would be to use one IPX socket for EACH unix user, and would require > a much more complex daemon/kernel. > > 3) Print Services. A netware aware lpd would be useful. Most important: > Should be one which could print from Unix to Netware AND vice-versa. > From owner-freebsd-hackers Wed Oct 18 14:02:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA21975 for hackers-outgoing; Wed, 18 Oct 1995 14:02:54 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA21956 ; Wed, 18 Oct 1995 14:02:48 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA05903; Wed, 18 Oct 1995 17:02:03 -0400 Date: Wed, 18 Oct 1995 17:02:03 -0400 From: "Garrett A. Wollman" Message-Id: <9510182102.AA05903@halloran-eldar.lcs.mit.edu> To: Terry Lambert Cc: bde@zeta.org.au (Bruce Evans), bakul@netcom.com, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? In-Reply-To: <199510181939.MAA00690@phaeton.artisoft.com> References: <199510180704.RAA16305@godzilla.zeta.org.au> <199510181939.MAA00690@phaeton.artisoft.com> Sender: owner-hackers@FreeBSD.org Precedence: bulk < said: > ] #define ARG_MAX 65536 /* max bytes for an exec function */ > Type: Bogus. Type: POSIX. > Required by: The process environment being in the user's address > space instead of attached to the proc structure and > accessed through system calls. BZZZZT! Wrong, but thanks for playing. You can ask David or John about the memory-fragmentation issues which mandate the use of a separate VM submap to hold this data while it is being staged between the old process and the new process. > ] #define CHILD_MAX 40 /* max simultaneous processes */ > Type: Administrative (compile time override) Type: Bogus but POSIX. > Required by: The ability for a user program to fork(2) the system to > death. BZZZZT! This value should be modifiable at run time. (It isn't yet.) > ] #define LINK_MAX 32767 /* max file link count */ > Type: Pragmatic Type: POSIX. > ] #define MAX_CANON 255 /* max bytes in term canon input line */ > Type: Bogus Type: POSIX. > ] #define NGROUPS_MAX 16 /* max supplemental group id's */ > Type: Standard (Interoperability, Legacy) > Required by: NFS, YP > Reason: Excess groups are truncated by the NFS external ID > representation mechanism. In point of fact, this > limit should be 8 to ensure interoperability with > older SVR3/SVR4 systems. No, the NFS and RPC code have their own kluges to deal with broken systems. > ] #define OPEN_MAX 64 /* max open files per process */ > Type: Bogus Type: POSIX. > ] #define PIPE_BUF 512 /* max bytes for atomic pipe writes */ > Type: Bogus Type: POSIX. > ] #define BC_BASE_MAX 99 /* max ibase/obase values in bc(1) */ > ] #define BC_DIM_MAX 2048 /* max array elements in bc(1) */ > ] #define BC_SCALE_MAX 99 /* max scale value in bc(1) */ > ] #define BC_STRING_MAX 1000 /* max const string length in bc(1) */ > ] #define COLL_WEIGHTS_MAX 0 /* max weights for order keyword */ > ] #define EXPR_NEST_MAX 32 /* max expressions nested in expr(1) */ > ] #define LINE_MAX 2048 /* max bytes in an input line */ > ] #define RE_DUP_MAX 255 /* max RE's in interval notation */ > Type: Bogus Type: POSIX. > Required by: A user space program Required by: IEEE-CS technical committee P1003.1. Any user-space program that executes `bc' to do arithmetic, or uses the LC_COLLATE localization support, or executes `expr' to do arithmetic. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-hackers Wed Oct 18 14:27:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA23281 for hackers-outgoing; Wed, 18 Oct 1995 14:27:43 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA23275 for ; Wed, 18 Oct 1995 14:27:39 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA00987; Wed, 18 Oct 1995 14:21:51 -0700 From: Terry Lambert Message-Id: <199510182121.OAA00987@phaeton.artisoft.com> Subject: Re: xterm dumps core To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Wed, 18 Oct 1995 14:21:51 -0700 (MST) Cc: ache@astral.msk.su, hackers@freefall.freebsd.org In-Reply-To: <199510181626.MAA29751@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 18, 95 12:26:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4347 Sender: owner-hackers@FreeBSD.org Precedence: bulk > The ANSI/POSIX/ISO locale model is inadequate for describing things > like I/O in a graphical user interface. One of the deficiencies is the > inability to describe a set of fonts to use for rendering text in an > arbitrary locale. Another deficiency is its failure to address input > methods, without which keyboard input in Oriental and Arabic languages > would be all but impossible. With the implementation of Unicode as a character set standard, the real issue has moved to either: 1) The deficiency in the Unicode standard in the placement of "private use" areas such that there is a *very* strong bias against fixed cell rendering technologies, like X, that use BLIT copies of prerendered characters at the server level. OR 2) The deficiency in X string drawing with regard to its choice of fixed cell as a rendering technology. The main issue here is whether a single "Unicode font" (in violation of the wishes of the authors of the Unicode standard, who happen to have a large economic interest in Adobe PostScript, so their opinions don't count for much) is possible or not. For non-ligatured languages (ie: not Arabic, Hebrew, Tamil, Devengari, or English script ["Cursive"]), the answer is "yes, it is possible, as long as we are talking about internationalization (enabling for soft localization to a single locale) instead of multinationalization (ability to simultaneously support multiple glyphs for a single character encoding, ie: the Han Unifications, etc.). For ligatured languages, it's possible to either adopt a locale regocognized block print font (Hebrew has one), or redefine the areas where the ligatured fonts lie as "private use" areas (in tacit violation of the standard), and respecify character encodings and round-trip tables for those languages. Keyboard input methodology is an interpretational issue, and is only loosely bound to the fact that X (improperly) assigns keycode values based on internal knowledge of keycap legends. This is loosely bound because of the ability to symbolically rebind these values with single forward table references. The "support for locale-based characater set designation" argues on the basis of a choice of a character set that is a subset of Unicode, or is an artifact of coding technique (ie: "xtamil"). I believe this to be a largely specious argument. What the ANSI/POSIX/ISO standards *do* lack is the ability to specify locale-based input methods for distinct sub-character set based locales as part of the locale information. This (and runic encoding at all) is why I believe that XPG/4 is itself bogus, thoughit is quite argualbe that locale specificity of input is a problem entirely addressable by hardware alone. Note that input method *could* be specified by locale specific hardware, as long as one was not intereted in multinationalization and/or various multilingual applications without a single round-trip standard for use in conversion to/from Unicode. > If you make changes like this without considering how it might affect > the things that have dependencies on them, you pretty much get what you > deserve. I'm sure you wouldn't make a gratuitous change like moving > printf out of libc would you? I agree with this summation. One must consider the ramifications of changes that will cause unexpected behavior that is not of a ducumented type. > If you're going to change your locale naming convention then you need > to document the change where people can find it and preserve the old > names (perhaps with symlinks) long enough that people can find either > the changes or the documentation and make the changes necessary in > their software to accomodate your changes. I don't think anyone has suggested directly modifying locale specification to anything other than ISO standards. The X locale alias mechanism is indeed an artifact of local extensions (ie: AIX "DOSANSI", HP, etc.) rather than an artifact of the deficiencies in the weel defined naming conventions for locales which are not vendor private. On the other hand, I have no problem whatsoever orphaning vendor-private locale naming mechanisms if it buys an additional level of functionality at no other cost. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Oct 18 14:52:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA24204 for hackers-outgoing; Wed, 18 Oct 1995 14:52:27 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA24198 ; Wed, 18 Oct 1995 14:52:16 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA01079; Wed, 18 Oct 1995 14:45:44 -0700 From: Terry Lambert Message-Id: <199510182145.OAA01079@phaeton.artisoft.com> Subject: Re: getdtablesize() broken? To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Wed, 18 Oct 1995 14:45:44 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, bakul@netcom.com, current@freefall.freebsd.org, hackers@freefall.freebsd.org In-Reply-To: <9510182102.AA05903@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 18, 95 05:02:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2693 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > ] #define ARG_MAX 65536 /* max bytes for an exec function */ > > > Type: Bogus. > > Type: POSIX. > > > Required by: The process environment being in the user's address > > space instead of attached to the proc structure and > > accessed through system calls. > > BZZZZT! Wrong, but thanks for playing. You can ask David or John > about the memory-fragmentation issues which mandate the use of a > separate VM submap to hold this data while it is being staged between > the old process and the new process. BZZZZT! Replace the enviornment with logical names and hang the logical name table off the proc struct instead of copying it like this and it won't *need* to be staged. Bye bye, staging area. Mark the environment as a shared copy-on-modification structure. > > ] #define CHILD_MAX 40 /* max simultaneous processes */ > > > Type: Administrative (compile time override) > > Type: Bogus but POSIX. > > > Required by: The ability for a user program to fork(2) the system to > > death. > > BZZZZT! This value should be modifiable at run time. (It isn't yet.) Posix? You mean by way of the limits code retrieving it? I never said that it shouldn't be modifiable at runtime, but "unlimited" is a valid value in POSIX. > > ] #define LINK_MAX 32767 /* max file link count */ > > Type: Pragmatic > Type: POSIX. Uh... where? Limits retrieval? > > ] #define MAX_CANON 255 /* max bytes in term canon input line */ > > Type: Bogus > Type: POSIX. Uh... where? POSIX doesn't mandate implementation. > > ] #define NGROUPS_MAX 16 /* max supplemental group id's */ > > Type: Standard (Interoperability, Legacy) > > Required by: NFS, YP > > Reason: Excess groups are truncated by the NFS external ID > > representation mechanism. In point of fact, this > > limit should be 8 to ensure interoperability with > > older SVR3/SVR4 systems. > > No, the NFS and RPC code have their own kluges to deal with broken > systems. You mean that they should. Try mounting an SVR4.0.2 NFS volume from a BSD system, and then accessing it from a credential with > 8 groups. > > ] #define OPEN_MAX 64 /* max open files per process */ > > Type: Bogus > Type: POSIX. Uh... where? Limits retrieval? > > ] #define PIPE_BUF 512 /* max bytes for atomic pipe writes */ > > Type: Bogus > Type: POSIX. ??? [ ... BC_ * ... ] > > Type: Bogus > > Type: POSIX. > > > Required by: A user space program > > Required by: IEEE-CS technical committee P1003.1. > > Any user-space program that executes `bc' to do arithmetic, or uses > the LC_COLLATE localization support, or executes `expr' to do > arithmetic. Yetch. Revised-Type: Gross, but POSIX From owner-freebsd-hackers Wed Oct 18 15:01:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA24604 for hackers-outgoing; Wed, 18 Oct 1995 15:01:22 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA24596 for ; Wed, 18 Oct 1995 15:01:17 -0700 Received: from exalt.x.org by expo.x.org id AA11342; Wed, 18 Oct 95 18:00:46 -0400 Received: from localhost by exalt.x.org id SAA00048; Wed, 18 Oct 1995 18:00:44 -0400 Message-Id: <199510182200.SAA00048@exalt.x.org> To: ache@astral.msk.su Cc: hackers@freefall.FreeBSD.org Subject: Re: xterm dumps core In-Reply-To: Your message of Wed, 18 Oct 1995 21:46:40 EST. Organization: X Consortium Date: Wed, 18 Oct 1995 18:00:44 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk >>Because OS vendors can't all agree on a single unified naming scheme >>it is necessary to have a mechanism to map from the various vendor locale >>names to the corresponding X name. That's all the locale.alias file is >>for. >So, it is definitely bug in locale.alias, it can't parse valid character >sets names which conforms RFC 1700. Bullshit. It is not a bug in X's locale.alias. I refuse to try to play "catch up" with unreleased version of an OS. How do I know you won't just change them again. When 2.1 is real I will consider changing them. >I simple follow existen standard for character set names, namely >RFC 1700. If X violates RFC 1700 Bullshit. X does not violate RFC 1700. The locale.alias table is there merely to provide *compatibility* with as many systems as possible. >(claiming itself as Standards Body :-) >sorry, can't resist) You should have. Saying stupid things doesn't help your case. >I don't think that it will be good to follow its >way only because it is X. Nobody has asked you to do any such thing. >Could you please pass this issue to X development team? I don't know if I can do that. >I mean that I have KOI8-R locale installed, i.e. this name >present in locale.dir, koi8-r/XLC_LOCALE, tbl_data/tabkoi8-r >and koi8-r fonts are installed. >xterm still dumps core for me. Why? I give up. Why? All the evidence thus far points to problems caused by changes you've made in FreeBSD. Get the source from XFree86. Compile it with debug, and solve your problem. >I don't plan provide backward compatible links, becase >it allows users to use completely non-standard locale names. This is one of the stupidest things I've heard lately. -- Kaleb KEITHLEY X Consortium From owner-freebsd-hackers Wed Oct 18 15:33:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA25845 for hackers-outgoing; Wed, 18 Oct 1995 15:33:53 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA25824 ; Wed, 18 Oct 1995 15:33:44 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id PAA27155; Wed, 18 Oct 1995 15:33:41 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id PAA29572; Wed, 18 Oct 1995 15:30:13 -0700 Message-Id: <199510182230.PAA29572@corbin.Root.COM> To: Terry Lambert cc: wollman@lcs.mit.edu (Garrett A. Wollman), bde@zeta.org.au, bakul@netcom.com, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? In-reply-to: Your message of "Wed, 18 Oct 95 14:45:44 PDT." <199510182145.OAA01079@phaeton.artisoft.com> From: David Greenman Reply-To: davidg@Root.COM Date: Wed, 18 Oct 1995 15:30:06 -0700 Sender: owner-hackers@FreeBSD.org Precedence: bulk >> > ] #define ARG_MAX 65536 /* max bytes for an exec function */ >> >> > Type: Bogus. >> >> Type: POSIX. >> >> > Required by: The process environment being in the user's address >> > space instead of attached to the proc structure and >> > accessed through system calls. >> >> BZZZZT! Wrong, but thanks for playing. You can ask David or John >> about the memory-fragmentation issues which mandate the use of a >> separate VM submap to hold this data while it is being staged between >> the old process and the new process. > >BZZZZT! Replace the enviornment with logical names and hang the logical >name table off the proc struct instead of copying it like this and it >won't *need* to be staged. Bye bye, staging area. Mark the environment >as a shared copy-on-modification structure. BZZZZT! Not if you want argv[] to work. We're not talking about just the environment variables. -DG From owner-freebsd-hackers Wed Oct 18 16:31:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA01603 for hackers-outgoing; Wed, 18 Oct 1995 16:31:30 -0700 Received: from hp-cv.cv.hp.com (hp-cv.cv.hp.com [15.255.72.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA01598 for ; Wed, 18 Oct 1995 16:31:24 -0700 Received: from hp-pcd.cv.hp.com by hp-cv.cv.hp.com with ESMTP (1.37.109.16/15.5+IOS 3.22+CV 1.0ext) id AA242209082; Wed, 18 Oct 1995 16:31:22 -0700 Received: from hpcvusd.cv.hp.com by hp-pcd.cv.hp.com with SMTP (1.37.109.16/15.5+IOS 3.22+OM+CV 1.0) id AA124379081; Wed, 18 Oct 1995 16:31:21 -0700 Received: from localhost by hpcvusd.cv.hp.com with SMTP (16.8/15.5+IOS 3.22[SMTP-rly]+CV 1.0leaf) id AA11772; Wed, 18 Oct 95 16:31:19 -0700 Message-Id: <9510182331.AA11772@hpcvusd.cv.hp.com> To: hackers@freebsd.org Reply-To: crosswjo@hp-pcd.cv.hp.com Subject: FreeBSD Kernel Development... Date: Wed, 18 Oct 95 16:31:19 -0700 From: John Crosswhite Sender: owner-hackers@freebsd.org Precedence: bulk I am most interested in learning how the FreeBSD kernel works on iX86 machines. Is there any sort of documentation (besides the code) that lends a general (to specific) explanation of the FreeBSD kernel design? Or just kernel design in general? I am looking for anything from a full text all the way down to FAQ. Thanks! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ John Crosswhite : E-Mail: crosswjo@cv.hp.com System Administrator : Office: 503-715-4170 Hewlett Packard - Corvallis Site : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-freebsd-hackers Wed Oct 18 16:31:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA01625 for hackers-outgoing; Wed, 18 Oct 1995 16:31:44 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA01620 for ; Wed, 18 Oct 1995 16:31:42 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id QAA21298; Wed, 18 Oct 1995 16:31:02 -0700 From: Julian Elischer Message-Id: <199510182331.QAA21298@ref.tfs.com> Subject: Re: device number for watchdog board driver To: terry@lambert.org (Terry Lambert) Date: Wed, 18 Oct 1995 16:31:01 -0700 (PDT) Cc: brian@MediaCity.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199510182052.NAA00890@phaeton.artisoft.com> from "Terry Lambert" at Oct 18, 95 01:52:14 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1440 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > > I have a device driver and support programs for the DVI Watchdog > > Reset board. > > > > Shall we get it its own major device number? > > > > The driver and support program have a copyright FreeBSD core > > members will probably be willing to co-habitat with. > > Contact Julian Elisher for documentation on the devfs device export > interface. Device numbers should no longer be assigned. hmm a LITTLE premature... I envision it will be a month or so until I have the time to make devfs as solid as it need to be.. (terry, you might like to lookat the code.. and figure out what needs to be done re: locking...It does nearly everything I want it to do from MY perspective, but I haven't cone through it with a fine toothed comb with an eye to correct handling of system resources yet.. in other words, it occasionally gets in a fight with some other module about owning a vnode. ) If you are ready to submit this driver, then I can assign you a major number. If you are just experimenting, use the 'local' number in the devsw table till you are ready to submit it.. if you want me to assign you a number, then that basically just requires that you send me the diffs you need to put into conf.c.. 'assigning a number' basically consists of checking it into conf.c. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > From owner-freebsd-hackers Wed Oct 18 16:37:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA01863 for hackers-outgoing; Wed, 18 Oct 1995 16:37:06 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA01858 for ; Wed, 18 Oct 1995 16:37:04 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id QAA09027 for ; Wed, 18 Oct 1995 16:36:54 -0700 Message-Id: <199510182336.QAA09027@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 to: freebsd-hackers@FreeBSD.ORG Subject: Re: device number for watchdog board driver In-reply-to: Your message of "Wed, 18 Oct 1995 13:52:14 PDT." <199510182052.NAA00890@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 16:36:53 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Dumb question: is there a command which I can use to display all the major and minor devices and hopefully the name of the device driver that the system knows about? Tnks, Amancio >>> Terry Lambert said: > > I have a device driver and support programs for the DVI Watchdog > > Reset board. > > > > Shall we get it its own major device number? > > > > The driver and support program have a copyright FreeBSD core > > members will probably be willing to co-habitat with. > > Contact Julian Elisher for documentation on the devfs device export > interface. Device numbers should no longer be assigned. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > From owner-freebsd-hackers Wed Oct 18 16:42:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA01981 for hackers-outgoing; Wed, 18 Oct 1995 16:42:04 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA01974 for ; Wed, 18 Oct 1995 16:42:02 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <17197(4)>; Wed, 18 Oct 1995 15:49:09 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Wed, 18 Oct 1995 15:48:37 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: jdl@chromatic.com cc: freebsd-hackers@freebsd.org Subject: Re: DNS question In-reply-to: Your message of "Wed, 18 Oct 95 07:27:38 PDT." <199510181427.JAA09753@chrome.jdl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 15:48:31 PDT From: Bill Fenner Message-Id: <95Oct18.154837pdt.177478@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510181427.JAA09753@chrome.jdl.com> you write: >Is there a way to reliably claim to do DNS for anything less than >a full Class-C subnet? The best way to do this is to have the person who is primary for 166.1.199.in-addr.arpa insert records like: jdl IN NS jdl.com. 200 IN CNAME 200.jdl 201 IN CNAME 201.jdl 202 IN CNAME 202.jdl ... 207 IN CNAME 207.jdl And then you can build a database for jdl.166.1.199.in-addr.arpa and you can be authoritative. I am sure that this is documented somewhere but can't figure out where. The most recent time I heard it described was at the NANOG meeting a month or so ago, and the person describing it said that people have been doing this for years. >Meta-question: Is there a better DNS list to question for this one? comp.protocols.tcp-ip.domains is probably a good place. Bill From owner-freebsd-hackers Wed Oct 18 16:51:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA02279 for hackers-outgoing; Wed, 18 Oct 1995 16:51:27 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA02260 for ; Wed, 18 Oct 1995 16:51:15 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA24562; Thu, 19 Oct 1995 00:51:07 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id AAA17261; Thu, 19 Oct 1995 00:51:07 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id XAA11564; Wed, 18 Oct 1995 23:42:31 +0100 From: J Wunsch Message-Id: <199510182242.XAA11564@uriah.heep.sax.de> Subject: Re: device number for watchdog board driver To: terry@lambert.org (Terry Lambert) Date: Wed, 18 Oct 1995 23:42:30 +0100 (MET) Cc: brian@MediaCity.com, freebsd-hackers@FreeBSD.ORG Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510182052.NAA00890@phaeton.artisoft.com> from "Terry Lambert" at Oct 18, 95 01:52:14 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 562 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk As Terry Lambert wrote: > > Contact Julian Elisher for documentation on the devfs device export > interface. Device numbers should no longer be assigned. Until devfs is really ready for prime time, i disagree. Brian, find somebody out of the ~ 50 commiters who would be willing to "mentor" your driver, and have him assigne you a major # by simply allocating that slot, and commiting the change. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Oct 18 16:51:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA02339 for hackers-outgoing; Wed, 18 Oct 1995 16:51:38 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA02334 ; Wed, 18 Oct 1995 16:51:34 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA24578; Thu, 19 Oct 1995 00:51:18 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id AAA17282; Thu, 19 Oct 1995 00:51:16 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id XAA11686; Wed, 18 Oct 1995 23:54:06 +0100 From: J Wunsch Message-Id: <199510182254.XAA11686@uriah.heep.sax.de> Subject: Re: lkm programming To: humprey@ccsread.dlsu.edu.ph (Humprey C. Sy) Date: Wed, 18 Oct 1995 23:54:05 +0100 (MET) Cc: hackers@freebsd.org, questions@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Humprey C. Sy" at Oct 18, 95 07:21:13 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 330 Sender: owner-hackers@freebsd.org Precedence: bulk As Humprey C. Sy wrote: > > Can anybody point me to some direction where I might get information on > implementing loadable kernel modules? /usr/share/examples/lkm/ -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Oct 18 17:14:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA03409 for hackers-outgoing; Wed, 18 Oct 1995 17:14:19 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA03402 ; Wed, 18 Oct 1995 17:14:16 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA01335; Wed, 18 Oct 1995 17:06:17 -0700 From: Terry Lambert Message-Id: <199510190006.RAA01335@phaeton.artisoft.com> Subject: Re: getdtablesize() broken? To: davidg@root.com Date: Wed, 18 Oct 1995 17:06:17 -0700 (MST) Cc: terry@lambert.org, wollman@lcs.mit.edu, bde@zeta.org.au, bakul@netcom.com, current@freefall.freebsd.org, hackers@freefall.freebsd.org In-Reply-To: <199510182230.PAA29572@corbin.Root.COM> from "David Greenman" at Oct 18, 95 03:30:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 779 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >> about the memory-fragmentation issues which mandate the use of a > >> separate VM submap to hold this data while it is being staged between > >> the old process and the new process. > > > >BZZZZT! Replace the enviornment with logical names and hang the logical > >name table off the proc struct instead of copying it like this and it > >won't *need* to be staged. Bye bye, staging area. Mark the environment > >as a shared copy-on-modification structure. > > BZZZZT! Not if you want argv[] to work. We're not talking about just the > environment variables. Damn. I thought this was for envp. 8-(. Never mind on that one, then. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Oct 18 17:17:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA03562 for hackers-outgoing; Wed, 18 Oct 1995 17:17:35 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA03557 for ; Wed, 18 Oct 1995 17:17:33 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA01374; Wed, 18 Oct 1995 17:11:10 -0700 From: Terry Lambert Message-Id: <199510190011.RAA01374@phaeton.artisoft.com> Subject: Re: device number for watchdog board driver To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Wed, 18 Oct 1995 17:11:10 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199510182336.QAA09027@rah.star-gate.com> from "Amancio Hasty Jr." at Oct 18, 95 04:36:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 411 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Dumb question: is there a command which I can use to display all the major > and minor devices and hopefully the name of the device > driver that the system knows about? You mean for the current system? cat /sys/sys/i386/conf.c You mean with a devfs? ls -lR /dev Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Oct 18 17:51:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA04028 for hackers-outgoing; Wed, 18 Oct 1995 17:51:54 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA04021 for ; Wed, 18 Oct 1995 17:51:51 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA01437; Wed, 18 Oct 1995 17:44:47 -0700 From: Terry Lambert Message-Id: <199510190044.RAA01437@phaeton.artisoft.com> Subject: Re: FreeBSD Kernel Development... To: crosswjo@hp-pcd.cv.hp.com Date: Wed, 18 Oct 1995 17:44:46 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <9510182331.AA11772@hpcvusd.cv.hp.com> from "John Crosswhite" at Oct 18, 95 04:31:19 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3139 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > I am most interested in learning how the FreeBSD kernel works on iX86 > machines. > > Is there any sort of documentation (besides the code) that lends a general > (to specific) explanation of the FreeBSD kernel design? Or just kernel > design in general? > > I am looking for anything from a full text all the way down to FAQ. Texts on kernel design in general: Title: "Unix Internals, the New Frontiers" Author: Uresh Vahalia Publisher: Prentice Hall/Simon and Schuster ISBN: 0-13-101908-2 Title: "The Design and Implementation of the 4.3 BSD UNIX Operating System" Author: Samuel J. Leffler, Marshall Kirk McKusick, Michael J. Karels, and John S. Quarterman Publisher: Addison-Wesley ISBN: 0-201-06196-1 The rest of my library is at home, but: Title: "UNIX for modern architectures" (?) Title: "The Magic Garden Explained" Title: "The UNIX System V Operating System" FTP sites: ftp.sage.usenix.org Various papers published in the "Proceedings of Usenix". ftp.cs.ucla.edu John Heidemann's Master's Thesis on stackable file system architecture (integrated in BSD 4.4 as the native VFS interface). Various related documents, many under the title "Ficus". ftp.digibd.com Draft version of the Spec 1170 document from the ftp.uiuinix.ui.org (UNIX International) FTP server (now defunct). ftp.cs.washington.edu Many papers on threading an SPARC ftp.sun.com Many papers on aspects of Solaris/SunOS. cs.utah.edu University of Utah projects involving Mach and BSD. Dynamic linking using C++ as a shared library implementation mechanism is highly recommended. etc. (OSF/Xerox/HP/DEC[gatekeeper.dec.com]/any university with graduate level CS, esp. MIT, etc.) Standards documents: POSIX 1003.1, 1003.2, 1003.8 ANSI X3J11 (ANSI C STANDARD -- ISO VERSION OF THIS DOCUMENT IS DRASTICALLY SUPERIOR!!!) SVID III System V Interface definition User/Programmer related documents: O'Reilly/Usenix BSD 4.4 manual set (5 books) UNIX Press's SVR4 books (full set is expensive!!!) Title: "The UNIX Programming Environment" Mail (autoresponder) standards documents: Dear EABI recipient: We have a new copy of the System V Release 4 ABI for PowerPC. This is the document the EABI supplies extensions to for embedded applications. If you wish to obtain a PostScript copy of this document, please send an email message to eabi@goth.sps.mot.com, with the word "SVR4" in the subject line. If you wish to obtain a PostScript copy of the EABI, please send an email message to eabi@goth.sps.mot.com, with the word "EABI" in the subject line. If you wish to obtain both, please send eabi@goth.sps.mot.com an email message with both words, "EABI" and "SVR4", in the subject line. If you wish to talk to a human, please send email to support@goth.sps.mot.com. Other references: Look in the bibliography of many of these books! Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Oct 18 17:53:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA04102 for hackers-outgoing; Wed, 18 Oct 1995 17:53:15 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA04095 for ; Wed, 18 Oct 1995 17:53:13 -0700 Received: from exalt.x.org by expo.x.org id AA13663; Wed, 18 Oct 95 20:52:41 -0400 Received: from localhost by exalt.x.org id UAA00286; Wed, 18 Oct 1995 20:52:36 -0400 Message-Id: <199510190052.UAA00286@exalt.x.org> To: Terry Lambert Cc: hackers@freefall.FreeBSD.org Subject: Re: xterm dumps core In-Reply-To: Your message of Wed, 18 Oct 1995 14:21:51 EST. <199510182121.OAA00987@phaeton.artisoft.com> Organization: X Consortium Date: Wed, 18 Oct 1995 20:52:36 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > > The ANSI/POSIX/ISO locale model is inadequate for describing things > > like I/O in a graphical user interface. One of the deficiencies is the > > inability to describe a set of fonts to use for rendering text in an > > arbitrary locale. Another deficiency is its failure to address input > > methods, without which keyboard input in Oriental and Arabic languages > > would be all but impossible. > > With the implementation of Unicode as a character set standard, the > real issue has moved to either: > > 1) The deficiency in the Unicode standard in the placement of > "private use" areas such that there is a *very* strong bias > against fixed cell rendering technologies, like X, that > use BLIT copies of prerendered characters at the server > level. > > OR > > 2) The deficiency in X string drawing with regard to its choice > of fixed cell as a rendering technology. I don't know of anyone that claims X is perfect. :-) > The main issue here is whether a single "Unicode font" is possible or not. Possible or practical given the current technology base? > For non-ligatured languages (ie: not Arabic, Hebrew, Tamil, Devengari, > or English script ["Cursive"]), the answer is "yes, it is possible, > as long as we are talking about internationalization (enabling for > soft localization to a single locale) ... Possible or practical given the current technology base? > ...instead of multinationalization > (ability to simultaneously support multiple glyphs for a single > character encoding, ie: the Han Unifications, etc.). You're talking about a stateful encoding, where the glyph for a particular character is dependent on preceeding or suceeding characters; conceptually similar to using compose sequences to enter characters in the right half of Latin-1 using a QWERTY keyboard, although that's probably an over- simplification. > For ligatured languages, it's possible to either adopt a locale > regocognized block print font (Hebrew has one), or redefine the > areas where the ligatured fonts lie as "private use" areas (in tacit > violation of the standard), and respecify character encodings and > round-trip tables for those languages. I believe we have stateful encodings right now. You seem to be saying that stateful encodings aren't possible in Unicode. > Keyboard input methodology is an interpretational issue, and is only > loosely bound to the fact that X (improperly) assigns keycode values > based on internal knowledge of keycap legends. This is loosely bound > because of the ability to symbolically rebind these values with single ^^^^^^^ ??? The ability or the inability to rebind values? > forward table references. > The "support for locale-based characater set designation" argues on the > basis of a choice of a character set that is a subset of Unicode, or > is an artifact of coding technique (ie: "xtamil"). > > I believe this to be a largely specious argument. I don't follow you. I'm confident that when vendors start supplying a Unicode locale, that the X locale mechanism is extensible and flexible enough to follow suit. > What the ANSI/POSIX/ISO standards *do* lack is the ability to specify > locale-based input methods for distinct sub-character set based locales > as part of the locale information. Do you mean e.g. the ability to switch to an alternative character set/ encoding such as Arabic in a Latin-1 locale? > This (and runic encoding at all) is why I believe that XPG/4 is itself > bogus, thoughit is quite argualbe that locale specificity of input > is a problem entirely addressable by hardware alone. > > Note that input method *could* be specified by locale specific hardware, > as long as one was not intereted in multinationalization and/or various > multilingual applications without a single round-trip standard for use > in conversion to/from Unicode. You lost me again. > > If you make changes like this without considering how it might affect > > the things that have dependencies on them, you pretty much get what you > > deserve. I'm sure you wouldn't make a gratuitous change like moving > > printf out of libc would you? > > I agree with this summation. One must consider the ramifications of > changes that will cause unexpected behavior that is not of a ducumented > type. > > > If you're going to change your locale naming convention then you need > > to document the change where people can find it and preserve the old > > names (perhaps with symlinks) long enough that people can find either > > the changes or the documentation and make the changes necessary in > > their software to accomodate your changes. > > I don't think anyone has suggested directly modifying locale specification > to anything other than ISO standards. No, but Andrey has said that he is going to/has already given new names to FreeBSD locales. I consider it a serious mistake to not maintain backwards compatibility with previous releases of FreeBSD. Even in going to HPUX-10, HP has maintained the HPUX-9 locale names. In HP's case the deprecated names will ultimately be deleted in an as yet unnamed release. Given how trivial it is to do this I fail to understand his blatant disregard for backwards compatibility from one release to the next. > The X locale alias mechanism is > indeed an artifact of local extensions (ie: AIX "DOSANSI", HP, etc.) > rather than an artifact of the deficiencies in the weel defined naming > conventions for locales which are not vendor private. An artifact of local extensions? I wouldn't say that. I would say it's an implementation detail to overcome the lack of consistency in naming locales, e.g.: HP's american.iso88591, Digital's en_US.ISO8859-1, SVR4's en_US, SunOS's iso_8859_1 LC_CTYPE, and all the other variations the vendors use for their ISO locale names. The X Consortium release of R6 makes no attempt to cover vendor proprietary locales like HP's roman8 locales, or AIX and Unixware Codepage 850 locales. As an aside I would say that I believe all these companies take their standards compliance very seriously. Yet none of them have a problem with not following RFC 7000 in choosing names for their locales. The switch from foo.ISO8859-1 to foo.ISO_8859-1 seems completely gratuitous. The fact that he will compound it by failing to have any sort of backwards compatibility is inexcusable. Andrey should think about the consequences of upsetting thousands of previously happy FreeBSD users when they discover that the X that they've been using just fine for a year or more on FreeBSD 2.0/2.0.5 no longer works, with problems ranging from xterm dumping core to compose processing no longer working. > On the other hand, I have no problem whatsoever orphaning vendor-private > locale naming mechanisms if it buys an additional level of functionality > at no other cost. This is not a case of X orphaning vendor locale names. It is a case of mapping as many vendor locale names as possible to the corresponding X locale name. It is a X internal implementation detail. It is not, as Andrey claims, a bug that the X Consortium release of R6 does not support the locale names used in an as yet unreleased version of FreeBSD. -- Kaleb From owner-freebsd-hackers Wed Oct 18 17:54:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA04171 for hackers-outgoing; Wed, 18 Oct 1995 17:54:01 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA04161 for ; Wed, 18 Oct 1995 17:53:59 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id RAA09347; Wed, 18 Oct 1995 17:53:22 -0700 Message-Id: <199510190053.RAA09347@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Terry Lambert cc: freebsd-hackers@FreeBSD.ORG Subject: Re: device number for watchdog board driver In-reply-to: Your message of "Wed, 18 Oct 1995 17:11:10 PDT." <199510190011.RAA01374@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 17:53:21 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Nope, I was hoping for something along the lines of sysctl which will tell me which devices the system things that it has in the *running kernel* sysctl -listdevices ?? or a functionally equivalent command. Amancio >>> Terry Lambert said: > > Dumb question: is there a command which I can use to display all the majo r > > and minor devices and hopefully the name of the device > > driver that the system knows about? > > You mean for the current system? > > cat /sys/sys/i386/conf.c > > You mean with a devfs? > > ls -lR /dev > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. From owner-freebsd-hackers Wed Oct 18 18:15:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA05400 for hackers-outgoing; Wed, 18 Oct 1995 18:15:11 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA05392 for ; Wed, 18 Oct 1995 18:15:08 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA01494; Wed, 18 Oct 1995 18:08:44 -0700 From: Terry Lambert Message-Id: <199510190108.SAA01494@phaeton.artisoft.com> Subject: Re: device number for watchdog board driver To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Wed, 18 Oct 1995 18:08:44 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199510190053.RAA09347@rah.star-gate.com> from "Amancio Hasty Jr." at Oct 18, 95 05:53:21 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 490 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Nope, > > I was hoping for something along the lines of sysctl which will tell > me which devices the system things that it has in the *running kernel* > > sysctl -listdevices ?? or a functionally equivalent command. > > > You mean with a devfs? > > > > ls -lR /dev This *is* the correct answer for that question as well, assuming devfs. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Oct 18 19:01:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA06833 for hackers-outgoing; Wed, 18 Oct 1995 19:01:20 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA06828 for ; Wed, 18 Oct 1995 19:01:07 -0700 Received: by sequent.kiae.su id AA20790 (5.65.kiae-2 ); Thu, 19 Oct 1995 05:59:36 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 19 Oct 95 05:59:35 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id EAA00479; Thu, 19 Oct 1995 04:58:30 +0300 To: "Kaleb S. KEITHLEY" Cc: hackers@freefall.FreeBSD.org References: <199510182200.SAA00048@exalt.x.org> In-Reply-To: <199510182200.SAA00048@exalt.x.org>; from "Kaleb S. KEITHLEY" at Wed, 18 Oct 1995 18:00:44 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 19 Oct 1995 04:58:30 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: xterm dumps core Lines: 78 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2770 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510182200.SAA00048@exalt.x.org> Kaleb S. KEITHLEY writes: >>>Because OS vendors can't all agree on a single unified naming scheme >>>it is necessary to have a mechanism to map from the various vendor locale >>>names to the corresponding X name. That's all the locale.alias file is >>>for. >>So, it is definitely bug in locale.alias, it can't parse valid character >>sets names which conforms RFC 1700. >Bullshit. It is not a bug in X's locale.alias. It seems that you understand what I want to say, but I'll try to play with terminology to make you more convenient if it ever possible. Change "bug" to "locale.alias is obsoleted" and add "real place to fix it is locale.alias". >I refuse to try to play "catch up" with unreleased version of an OS. >How do I know you won't just change them again. When 2.1 is real I >will consider changing them. I don't change them again until ISO decides to renames their charsets. >>I simple follow existen standard for character set names, namely >>RFC 1700. If X violates RFC 1700 >Bullshit. X does not violate RFC 1700. The locale.alias table is >there merely to provide *compatibility* with as many systems as >possible. Continue play with terminology... Maybe words "RFC 1700 names not supported by X" instead of "violated" sounds better? >>(claiming itself as Standards Body :-) >>sorry, can't resist) >You should have. Saying stupid things doesn't help your case. I don't need any help here. I assume that Standard Body must care to _support_ standards at least, isn't? >>I don't think that it will be good to follow its >>way only because it is X. >Nobody has asked you to do any such thing. _You_ ask me to keep backward links to invalid names. >>I mean that I have KOI8-R locale installed, i.e. this name >>present in locale.dir, koi8-r/XLC_LOCALE, tbl_data/tabkoi8-r >>and koi8-r fonts are installed. >>xterm still dumps core for me. Why? >I give up. Why? All the evidence thus far points to problems caused >by changes you've made in FreeBSD. Get the source from XFree86. Compile >it with debug, and solve your problem. Well, I just send a copy to you and not asking for help in this case, I ask Dawes for help. >>I don't plan provide backward compatible links, becase >>it allows users to use completely non-standard locale names. >This is one of the stupidest things I've heard lately. Ok, also I have opinion of your conversation style, I'll resist to public it in this case... -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Wed Oct 18 19:16:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA07036 for hackers-outgoing; Wed, 18 Oct 1995 19:16:05 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA07030 for ; Wed, 18 Oct 1995 19:16:00 -0700 Received: by sequent.kiae.su id AA22748 (5.65.kiae-2 ); Thu, 19 Oct 1995 06:13:58 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 19 Oct 95 06:13:57 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id FAA00538; Thu, 19 Oct 1995 05:13:22 +0300 To: "Kaleb S. KEITHLEY" , Terry Lambert Cc: hackers@freefall.FreeBSD.org References: <199510190052.UAA00286@exalt.x.org> In-Reply-To: <199510190052.UAA00286@exalt.x.org>; from "Kaleb S. KEITHLEY" at Wed, 18 Oct 1995 20:52:36 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 19 Oct 1995 05:13:22 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: xterm dumps core Lines: 59 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2936 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510190052.UAA00286@exalt.x.org> Kaleb S. KEITHLEY writes: >> The X locale alias mechanism is >> indeed an artifact of local extensions (ie: AIX "DOSANSI", HP, etc.) >> rather than an artifact of the deficiencies in the weel defined naming >> conventions for locales which are not vendor private. >An artifact of local extensions? I wouldn't say that. I would say it's >an implementation detail to overcome the lack of consistency in naming >locales, e.g.: HP's american.iso88591, Digital's en_US.ISO8859-1, SVR4's >en_US, SunOS's iso_8859_1 LC_CTYPE, and all the other variations the >vendors use for their ISO locale names. The X Consortium release of R6 >makes no attempt to cover vendor proprietary locales like HP's roman8 >locales, or AIX and Unixware Codepage 850 locales. This problem leads to using identifiers which is home-made, RFC 1700 takes care just of this case, now anybody who want follows standard here know which charset names he must choose. >As an aside I would say that I believe all these companies take their >standards compliance very seriously. Yet none of them have a problem with >not following RFC 7000 in choosing names for their locales. The switch RFC 1700 is relatively new, so following expected. BTW, it uses original ISO charsets names which _always_ exists. >from foo.ISO8859-1 to foo.ISO_8859-1 seems completely gratuitous. The fact >that he will compound it by failing to have any sort of backwards >compatibility is inexcusable. >Andrey should think about the consequences of upsetting thousands of >previously happy FreeBSD users when they discover that the X that they've >been using just fine for a year or more on FreeBSD 2.0/2.0.5 no longer >works, with problems ranging from xterm dumping core to compose processing >no longer working. X shipped on the same CD as FreeBSD and it is newer that 2.0/2.0.5 variant, so upgrading recommended in this case. I already make neccessary locale.alias additions. >> On the other hand, I have no problem whatsoever orphaning vendor-private >> locale naming mechanisms if it buys an additional level of functionality >> at no other cost. >This is not a case of X orphaning vendor locale names. It is a case of >mapping as many vendor locale names as possible to the corresponding X >locale name. It is a X internal implementation detail. It is not, as Andrey >claims, a bug that the X Consortium release of R6 does not support the >locale names used in an as yet unreleased version of FreeBSD. I mean that X Consotrium not support RFC 1700 names when it should. FreeBSD unreleased version is working example of it. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Wed Oct 18 19:18:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA07123 for hackers-outgoing; Wed, 18 Oct 1995 19:18:31 -0700 Received: from ns.easy.re.kr ([203.241.171.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA07118 for ; Wed, 18 Oct 1995 19:18:19 -0700 Received: (from moonhunt@localhost) by ns.easy.re.kr (8.6.12H1/8.6.9) id LAA01292; Thu, 19 Oct 1995 11:06:32 +0900 From: HyunSeog Ryu Message-Id: <199510190206.LAA01292@ns.easy.re.kr> Subject: Re: device number for watchdog board driver To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Thu, 19 Oct 1995 11:06:32 +1553003 (KST) Cc: hackers@freebsd.org In-Reply-To: <199510182336.QAA09027@rah.star-gate.com> from "Amancio Hasty Jr." at Oct 18, 95 04:36:53 pm X-Mailer: ELM [version 2.4 PL21-h4] Content-Type: text Content-Length: 814 Sender: owner-hackers@freebsd.org Precedence: bulk > > > Dumb question: is there a command which I can use to display all the major > and minor devices and hopefully the name of the device > driver that the system knows about? You can refer /sys/i386/conf/devices.i386 for major number... But minor number ??? ;> And you can refer lsdev command also... > > Tnks, > Amancio Hyunseog Ryu =============================================================================== Name : Hyunseog Ryu moonhunt@easy.re.kr Tel : +82-2-884-0174 http://www.easy.re.kr/~moonhunt Fax : +82-2-884-0175 :-) EASY research institute Tomorrow is another day... ;> 4th floor, 304-25, shinrim 10-dong For better world, cheers!!! Kwanak-gu, Seoul, 151-020, Korea :-D =============================================================================== From owner-freebsd-hackers Wed Oct 18 19:27:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA07413 for hackers-outgoing; Wed, 18 Oct 1995 19:27:00 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA07408 for ; Wed, 18 Oct 1995 19:26:55 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA01615; Wed, 18 Oct 1995 19:20:56 -0700 From: Terry Lambert Message-Id: <199510190220.TAA01615@phaeton.artisoft.com> Subject: Re: xterm dumps core To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Wed, 18 Oct 1995 19:20:55 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.FreeBSD.org In-Reply-To: <199510190052.UAA00286@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 18, 95 08:52:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 15340 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > The main issue here is whether a single "Unicode font" is possible or not. > > Possible or practical given the current technology base? Both, since I have a 14 point font that is complete except for ligatured languages, and there is a company in Taiwan that has a uxterm and a *bunch* of fonts along the same lines, plus they do the dancing to support the ligatured stuff. > > For non-ligatured languages (ie: not Arabic, Hebrew, Tamil, Devengari, > > or English script ["Cursive"]), the answer is "yes, it is possible, > > as long as we are talking about internationalization (enabling for > > soft localization to a single locale) ... > > Possible or practical given the current technology base? Both. Less than 1M of ROM for inclusion in an xterminal. ROM is cheap. > > ...instead of multinationalization > > (ability to simultaneously support multiple glyphs for a single > > character encoding, ie: the Han Unifications, etc.). > > You're talking about a stateful encoding, where the glyph for a particular > character is dependent on preceeding or suceeding characters; conceptually > similar to using compose sequences to enter characters in the right half > of Latin-1 using a QWERTY keyboard, although that's probably an over- > simplification. Not really. Unicode calls multiple simultaneous languages in unshared character set standards for round-tripping "Rich Text Format". The rest of the world would call this a "Compound Document". For ligatured languages, the glyph selection can be on the basis of the ordinal in the round trip set being multiplied by some constant and then added to a constant offset to get the encoding area in Unicode. The selection of the actual glyph to be displayed from the set of those of [0..(constant-1)] is done on the basis of dividing the constant into 4 zones: (i) space before (ii) space after (iii) no space (entry), and (iv) no space (exit). This allows up to (constant/4) ligature joining points from character to character. Then drawing is done on the basis of precomputation of adjacency in the application text draw library. Expensive, but less expensive than ruling out X fonts as a rendering technology and computing the ligatures at run time into a bitmap and copying it down. > > For ligatured languages, it's possible to either adopt a locale > > regocognized block print font (Hebrew has one), or redefine the > > areas where the ligatured fonts lie as "private use" areas (in tacit > > violation of the standard), and respecify character encodings and > > round-trip tables for those languages. > > I believe we have stateful encodings right now. You seem to be saying > that stateful encodings aren't possible in Unicode. They aren't. You must use a "Rich Text Format", and then choose to do the conversion from the ordinal value into a character/font selector from that information, or you must allow them in Unicode by wedging them in -- though the only languages that would require this are those that require ligaturing. For the previous zone example, a 16:1 compatability would provide a 2 pixel variance on an 8 point font: sufficient to produce reasonable test from the data without font switching, only zone/boundry comparisons in selecting which of the 16 glyphs for each character should be used to line up with the ligature point on the next character. > > Keyboard input methodology is an interpretational issue, and is only > > loosely bound to the fact that X (improperly) assigns keycode values > > based on internal knowledge of keycap legends. This is loosely bound > > because of the ability to symbolically rebind these values with single > ^^^^^^^ > ??? The ability or the inability to rebind values? Ability. If the keycodes weren't run through a translation prior to use (ie: the program didn't follow the rules on allowing key bindings), then it would be tightly bound. > > forward table references. > > > The "support for locale-based characater set designation" argues on the > > basis of a choice of a character set that is a subset of Unicode, or > > is an artifact of coding technique (ie: "xtamil"). > > > > I believe this to be a largely specious argument. > > I don't follow you. I'm confident that when vendors start supplying a > Unicode locale, that the X locale mechanism is extensible and flexible > enough to follow suit. The problem is that Unicode is a character set standard, not a glyph encoding standard... at least that is the intent. That means that it's an OK process encoding standard and an OK storage encoding standard, but that you are expected to either make a round trip conversion to another character set to do the display, or you are expected to implement a subset font that is representative of the code points in a round trip standard that are in Unicode, and no other characters in Unicode. Consider a document in Japanese that describes "how to read Chinese"; the characters in the description and in the described text could very well have been unified to single code points, and thus the attribution of font is outside the scope of Unicode itself (there exists no standard character set that contains both Chinese and Japanese as seperate entities). Pragmatically, it would be useful to be able to display all characters in a file as if they were Unicode characters, and not be so anal about the actual locale they were generated in. That is, you would display Chinese characters as if they were Japanese, etc. as a side effect of the CJK Unification. This is especially useful if you did an "ls -R" on a data vault or some other shared storage system. So while there is no such thing as a "Unicode" locale, nor can there be, it would be useful to pretend that one existed for purely pragmatic reasons. If we get into font switching, then there is little difference between selecting glyphs by ligatured character adjacency vs. selecting them by "Rich Text" desination of the real locale for the characters; at the point you start switching fonts, you've already lost what little margin you had available to you to "pretend" there was a single locale, and you start dragging in abstractions built on "FontSet" selection into each and every program that expects to be able to display data. > > What the ANSI/POSIX/ISO standards *do* lack is the ability to specify > > locale-based input methods for distinct sub-character set based locales > > as part of the locale information. > > Do you mean e.g. the ability to switch to an alternative character set/ > encoding such as Arabic in a Latin-1 locale? No. The character set for an input device is never Unicode; Humans haven't unified all keyboard input mechanisms for all human languages, largely because the keyboards have keycap legends and so it is not really possible to do it cleanly. I suppose you could look at it as picking a character set which you will then round-trip to Unicode process encoding by virtue of the device you have chosen to use for your input. The closest you could get to actual switchable attribution would be for a multilingual touch-typist for keyboards with identical form factors and no keycap markings, or little display panels on each key to allow variation in keycap from moment to moment (I claim prior art on this if anyone goes off and implements one 8-)). Since typical usage of a computer occurs in the common character set for a given locale (indeed, there is currently no other choice because of conflicts in round-tripping standards), the expense of trying to do something like that would outweigh the returns. The "Arabic"/"Latin-1" example you give is actually a conflict case, since the Arabic character set standard is a superset of ASCII, as is Latin-1, but the standards are intersecting (except under Unicode unification), and so no keyboard exists for handling both. Latin-1 is mabye a bad techinical example, since one could see using NRCS type character replacement or DEC-style character composition to either use a 7 bit ASCII varient in place of the ASCII in the Arabic character set, or using an already familiar chording that would be applicable on an Arabic/QWERTY dual function keyboard (though from my experience, I'd say there would be conflict over the ALT-key usage, I think it would be resolvable, either by dead-key or secondary control key redesignation). A better example of an "impossible" switch would be Cyrillic/Greek or some other combination (Japanese/Chinese), where the "unified" keycap legends would be too much. > > This (and runic encoding at all) is why I believe that XPG/4 is itself > > bogus, thoughit is quite argualbe that locale specificity of input > > is a problem entirely addressable by hardware alone. > > > > Note that input method *could* be specified by locale specific hardware, > > as long as one was not intereted in multinationalization and/or various > > multilingual applications without a single round-trip standard for use > > in conversion to/from Unicode. > > You lost me again. You get a keyboard specific to your locale's character set standard, and since you can only physically be in one locale at a time, unless you attempt multiligual editing with conflicting standards, you can choose to use the "right" keyboard. Such a keyboard could generate Unicode 16 bit characters and up/down and modifier encodings, such that the keyboard would be what you replaced when switching locales. That would save you all of the software crap you have to go through matching identical keycodes to locale-based keycap legends. This would be the ideal soloution, but it will be a cold day in hell before we see it happen. 8-). This would save XPG/4 type input of "all character sets into the same funnel", which is otherwise objectionable. > > > If you're going to change your locale naming convention then you need > > > to document the change where people can find it and preserve the old > > > names (perhaps with symlinks) long enough that people can find either > > > the changes or the documentation and make the changes necessary in > > > their software to accomodate your changes. > > > > I don't think anyone has suggested directly modifying locale specification > > to anything other than ISO standards. > > No, but Andrey has said that he is going to/has already given new names > to FreeBSD locales. I consider it a serious mistake to not maintain > backwards compatibility with previous releases of FreeBSD. Even in going > to HPUX-10, HP has maintained the HPUX-9 locale names. In HP's case the > deprecated names will ultimately be deleted in an as yet unnamed release. > Given how trivial it is to do this I fail to understand his blatant > disregard for backwards compatibility from one release to the next. Arguably, this could be our "as yet unnamed release". How long would you suggest keeping the window open? It has been open for one release so far. It's premature to discuss this in the context of X, though: as you pointed out, there is no point in discussing X until a release is cut and the code isn't going to randomly change out from under you. The question is really one of how quickly an automated process can be put in place that hides the actual values from the user. Once that has been done, Andrey can deprecate to his heart's content and not affect anything but software complexity (reducing it). Locale is almost entirely data-driven, so it is uniquely immune (well, relatively immune anyway) to legacy code. You only have legacy problems if there is hard-coding in binaries, and that's against the usage rules in the first place. Punishing rule-breakers is less of an ethical problem than punishing your average user. > > The X locale alias mechanism is > > indeed an artifact of local extensions (ie: AIX "DOSANSI", HP, etc.) > > rather than an artifact of the deficiencies in the weel defined naming > > conventions for locales which are not vendor private. > > An artifact of local extensions? I wouldn't say that. I would say it's > an implementation detail to overcome the lack of consistency in naming > locales, e.g.: HP's american.iso88591, Digital's en_US.ISO8859-1, SVR4's > en_US, SunOS's iso_8859_1 LC_CTYPE, and all the other variations the > vendors use for their ISO locale names. The X Consortium release of R6 > makes no attempt to cover vendor proprietary locales like HP's roman8 > locales, or AIX and Unixware Codepage 850 locales. Well, the locale comes from data and is used to map other data. The problem is in the systems attempting to support non-data driven first cause lookups. In the end, the translation from the implementation specific locale names should be *to* the official names. If X has the official names and FreeBSD has the official names, then there isn't a problem dropping the support in FreeBSD. What Andrey *might* be overlooking is when the X server is FreeBSD and the client is one of the legacy systems. > As an aside I would say that I believe all these companies take their > standards compliance very seriously. Yet none of them have a problem with > not following RFC 7000 in choosing names for their locales. The switch > from foo.ISO8859-1 to foo.ISO_8859-1 seems completely gratuitous. The fact > that he will compound it by failing to have any sort of backwards > compatibility is inexcusable. The backward compatability won't be an issue for the Pure BSD environemnt; if X throws around only official names internally for things like font selection, then he should be safe dropping non-RFC 7000 locales entirely. > Andrey should think about the consequences of upsetting thousands of > previously happy FreeBSD users when they discover that the X that they've > been using just fine for a year or more on FreeBSD 2.0/2.0.5 no longer > works, with problems ranging from xterm dumping core to compose processing > no longer working. Using "on" FreeBSD shouldn't be a problem. Data is data, as long as it matches. Using "with" FreeBSD could definitely blow him out of the water if X isn't RFC 7000 internally. > > On the other hand, I have no problem whatsoever orphaning vendor-private > > locale naming mechanisms if it buys an additional level of functionality > > at no other cost. > > This is not a case of X orphaning vendor locale names. It is a case of > mapping as many vendor locale names as possible to the corresponding X > locale name. It is a X internal implementation detail. It is not, as Andrey > claims, a bug that the X Consortium release of R6 does not support the > locale names used in an as yet unreleased version of FreeBSD. I'd argue that there is a difference between "compliant names" and "correct names". Andrey can have one or the other, but not both. The orphaning of vendor private locales may in fact orphan FreeBSD-private locales (ie: KOI8-R). There is a strong emphasis here on X needing to use RFC 7000 for internal names after doing the alias lookup of a potentially vendor-private locale. I agree that the aliases file itself is an implementation detail, and may be a non-issue entirely, depending on the representation used between the client and the server. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Oct 18 19:29:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA07461 for hackers-outgoing; Wed, 18 Oct 1995 19:29:36 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA07456 for ; Wed, 18 Oct 1995 19:29:28 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id MAA13953; Thu, 19 Oct 1995 12:33:47 +0930 From: Michael Smith Message-Id: <199510190303.MAA13953@genesis.atrad.adelaide.edu.au> Subject: Re: FreeBSD Kernel Development... To: hackers@freebsd.org Date: Thu, 19 Oct 1995 12:33:47 +0930 (CST) Cc: crosswjo@hp-pcd.cv.hp.com In-Reply-To: <199510190044.RAA01437@phaeton.artisoft.com> from "Terry Lambert" at Oct 18, 95 05:44:46 pm Content-Type: text Content-Length: 1540 Sender: owner-hackers@freebsd.org Precedence: bulk Terry Lambert stands accused of saying: > > Is there any sort of documentation (besides the code) that lends a general > > (to specific) explanation of the FreeBSD kernel design? Or just kernel > > design in general? > > > > I am looking for anything from a full text all the way down to FAQ. > Title: "The Design and Implementation of the 4.3 BSD > UNIX Operating System" This book is pretty good. You can tell that these guys have been around the traps, and have a pretty good idea what it's all about. Some parts are a little Vax-centric and smug, but in context, that's quite forgivable 8) > Title: "The Magic Garden Explained" This book is _very_ frustrating. Aside from the inconsistencies in formatting and syntax, it wanders all over the place, varying from intense and detailed to frustratingly vague. I've never been able to get a good flow up reading it 8(. Having said that, it _does_ contain an awful lot of very interesting information, and I've learnt a lot from it. (Being Tandem employees, some of the low-level discussion is around the MIPS R3000 architecture, which isn't as much fun as the Vax 8) > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Wed Oct 18 19:39:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA07728 for hackers-outgoing; Wed, 18 Oct 1995 19:39:19 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA07718 ; Wed, 18 Oct 1995 19:39:10 -0700 Received: by sequent.kiae.su id AA25400 (5.65.kiae-2 ); Thu, 19 Oct 1995 06:34:59 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 19 Oct 95 06:34:58 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id FAA00607; Thu, 19 Oct 1995 05:29:49 +0300 To: Terry Lambert Cc: Bruce Evans , core@FreeBSD.ORG, hackers@FreeBSD.ORG, kaleb@x.org, phk@critter.tfs.com, wollman@lcs.mit.edu References: <199510182046.NAA00860@phaeton.artisoft.com> In-Reply-To: <199510182046.NAA00860@phaeton.artisoft.com>; from Terry Lambert at Wed, 18 Oct 1995 13:46:37 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 19 Oct 1995 05:29:49 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: Locale stuff: call for conclusion. Lines: 36 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1623 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message <199510182046.NAA00860@phaeton.artisoft.com> Terry Lambert writes: >> > Use ISO 8859-1 as the C locale. >> >> We already agree. I expect some sort of patch from you or Kaleb. >Copy the 8859-1 US locale. No real patch is needed. Wait. I remember Bruce's proposal to eliminate all upper/lower tags, he refers to ANSI here and Kaleb agrees. I have several ideas in this direction: maybe remove punct, space and alpha tags too? I.e. made it in two parts: control & printable. Or maybe three parts (control/printable/alpha)? Bruce, what you can say? >The ability to link XPG/3 by default and XPG/4 by option is required >to support the optional rather than the "all or nothing" transition >between "i18n function" and "full function". >The reason to "mess with the linker" is so that XPG/4 binaries are >not required to be statically linked and we are not required to >maintain a full seperate C library, only an XPG/4 library. Otherwise >XPG/4 internationalization is second class twice: once because of the >effort to go XPG/3->XPG/4, and once because of the link differences >and (potentially) the larger static binary. Well, so lets put XPG3 library into libc and made additional XPG4 library linked by -lxpg4. I assume that two libraries will be made from same sources, of course. Do you agree with that? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Wed Oct 18 19:40:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA07849 for hackers-outgoing; Wed, 18 Oct 1995 19:40:13 -0700 Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA07821 for ; Wed, 18 Oct 1995 19:39:56 -0700 Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id MAA14718; Thu, 19 Oct 1995 12:37:15 +1000 From: David Dawes Message-Id: <199510190237.MAA14718@rf900.physics.usyd.edu.au> Subject: Re: xterm dumps core To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Thu, 19 Oct 1995 12:37:15 +1000 (EST) Cc: hackers@freebsd.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 18, 95 04:49:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 948 Sender: owner-hackers@freebsd.org Precedence: bulk >In message <199510180847.SAA12056@rf900.physics.usyd.edu.au> David > Dawes writes: > >>Does this mean that the default locale names have been changed in -current >>to include these underscores? On 2.0.5, they don't have them. If I do: > >Yes, locale names in current and stable conforms RFC 1700 (valid charset >names list registered by IANA). >ISO8859-1 is _invalid_ name. I just checked a machine I have running a recent SNAP (951005), and it still uses the old names. Has this been changed in stable since then? >>I think the reason for this one is that the locale name "de_DE.ISO_8859-1" >>is not present in the XLOCALE database. If I add the line: > >>de_DE.ISO_8859-1 de_DE.ISO8859-1 > >>to /usr/X11R6/lib/X11/locale/locale.alias > >>xterm doesn't dump core any more. > >Why xterm even use locale.alias? I think XFree for FreeBSD builds >for using _system_ locale instead of shipped with X. I think Kaleb has answered this. David From owner-freebsd-hackers Wed Oct 18 19:46:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA08227 for hackers-outgoing; Wed, 18 Oct 1995 19:46:48 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA08219 for ; Wed, 18 Oct 1995 19:46:44 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id TAA10415; Wed, 18 Oct 1995 19:45:03 -0700 Message-Id: <199510190245.TAA10415@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: HyunSeog Ryu cc: hackers@freebsd.org Subject: Re: device number for watchdog board driver In-reply-to: Your message of "Thu, 19 Oct 1995 11:06:32 +1553." <199510190206.LAA01292@ns.easy.re.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 19:45:02 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk >>> HyunSeog Ryu said: > > > > > > Dumb question: is there a command which I can use to display all the majo r > > and minor devices and hopefully the name of the device > > driver that the system knows about? > You can refer /sys/i386/conf/devices.i386 for major number... Yes, I know about that lets assume that I visit a FreeBSD box and that /sys is not there. > But minor number ??? ;> > And you can refer lsdev command also... Nice listing but there is no association between the nice output of lsdev and /dev: lsdev -cv # This listing automatically generated by lsdev(1) 1: # CPU cpu0 2: controller scbus0 3: controller isa0 4: sc0 at isa? tty (id 8) port 0x60 irq 1 5: ed0 at isa? net (id 14) port 0x240 irq 9 iomem 0xd4000 iosiz 16384 6: ed1 at isa? net (id 15) port 0x280 irq 5 iomem 0xd8000 iosiz 8192 7: sio0 at isa? tty (id 9) port 0x3f8 irq 4 8: sio1 at isa? tty (id 10) port 0x2f8 irq 3 9: sio2 at isa? tty (id 11) port 0x3e8 irq 5 10: lpt0 at isa? tty (id 12) port 0x378 irq 7 11: lpt1 at isa? tty (id 13) port ? 12: fdc0 at isa? bio (id 2) port 0x3f0 irq 6 drq 2 13: fd0 at fdc0 drive 0 14: wdc0 at isa? (id 3) port 0x1f0 irq 14 15: wd0 at wdc0 drive 0 16: aha0 at isa? bio (id 6) port 0x330 drq 5 17: aic0 at isa? bio (id 7) port 0x340 irq 11 18: npx0 at isa? (id 16) port 0xf0 19: chip0 at pci0:0 20: chip1 at pci0:7 21: vga0 at pci0:11 # int a irq 10 22: ahc0 at pci0:12 # int a irq 11 23: sd0 at SCSI bus 0:0:0 (ready) (open) 24: cd0 at SCSI bus 0:2:0 25: sd1 at SCSI bus 0:6:0 (ready) (open) I guess that is too hard for a program to figure out the association of a device driver with the major and minor number in /dev :> Also not to mention that loadable modules are not listed... I was thinking more along the lines of : 25: sd1 at SCSI bus 0:6:0 (ready) (open) 4, 65546 /dev/sd1 4, 8 /dev/sd1a 4, 9 /dev/sd1b .... You see as more drivers and/or loadable modules get added to FreeBSD it becomes rather nice to issue a single command to figure out what is on the system. Enjoy, Amancio From owner-freebsd-hackers Wed Oct 18 20:01:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA09041 for hackers-outgoing; Wed, 18 Oct 1995 20:01:18 -0700 Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA09031 for ; Wed, 18 Oct 1995 20:00:57 -0700 Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id MAA14837; Thu, 19 Oct 1995 12:57:58 +1000 From: David Dawes Message-Id: <199510190257.MAA14837@rf900.physics.usyd.edu.au> Subject: Re: Well, I have proper name & X locale installed, why xterm still To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Thu, 19 Oct 1995 12:57:58 +1000 (EST) Cc: hackers@freebsd.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 18, 95 10:45:02 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1126 Sender: owner-hackers@freebsd.org Precedence: bulk >I mean that I have KOI8-R locale installed, i.e. this name >present in locale.dir, koi8-r/XLC_LOCALE, tbl_data/tabkoi8-r >and koi8-r fonts are installed. > >xterm still dumps core for me. Why? Don't know. When I have these installed it works fine for me. >Dawes, I already sent you related materials, so you can test >them on your own machine, please help. They are the ones I have installed (they are part of our current alpha version of XFree86). I have the following under /usr/X11R6/lib/X11/locale: koi8-r/XLC-LOCALE tbl_data/tabkoi8-r In locale.dir, I have a line: koi8-r/XLC_LOCALE ru_RU.KOI8-R and in locale.alias, I have the following line: ru_SU.KOI8-R ru_RU.KOI8-R When I then do: setenv ENABLE_STARTUP_LOCALE setenv LANG ru_SU.KOI8-R and start xterm, it starts up without any problems. If I remove either of those lines from locale.dir or locale.alias it dumps core (and dumps core rather than just ignoring a locale it doesn't recognise only because the assumption that the initial locale is "C" isn't true). Perhaps you should send me your /usr/X11R6/lib/X11/locale directory. David From owner-freebsd-hackers Wed Oct 18 20:04:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA09184 for hackers-outgoing; Wed, 18 Oct 1995 20:04:58 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id UAA09167 for ; Wed, 18 Oct 1995 20:04:44 -0700 Received: by sequent.kiae.su id AA01524 (5.65.kiae-2 ); Thu, 19 Oct 1995 06:58:00 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 19 Oct 95 06:57:59 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id FAA00728; Thu, 19 Oct 1995 05:56:11 +0300 To: David Dawes Cc: hackers@freebsd.org References: <199510190237.MAA14718@rf900.physics.usyd.edu.au> In-Reply-To: <199510190237.MAA14718@rf900.physics.usyd.edu.au>; from David Dawes at Thu, 19 Oct 1995 12:37:15 +1000 (EST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 19 Oct 1995 05:56:10 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: xterm dumps core Lines: 26 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1140 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510190237.MAA14718@rf900.physics.usyd.edu.au> David Dawes writes: >>In message <199510180847.SAA12056@rf900.physics.usyd.edu.au> David >> Dawes writes: >> >>>Does this mean that the default locale names have been changed in -current >>>to include these underscores? On 2.0.5, they don't have them. If I do: >> >>Yes, locale names in current and stable conforms RFC 1700 (valid charset >>names list registered by IANA). >>ISO8859-1 is _invalid_ name. >I just checked a machine I have running a recent SNAP (951005), and it still >uses the old names. Has this been changed in stable since then? It seems that you still have obsoleted names from previous versions. You need to say "make distrib-dirs" in /usr/src/etc, remove obsoleted dirs and re-build/install /usr/src/bin/{mklocale,colldef} and /usr/src/share/timedef. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Wed Oct 18 20:21:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA10547 for hackers-outgoing; Wed, 18 Oct 1995 20:21:38 -0700 Received: from ns.easy.re.kr ([203.241.171.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA10513 for ; Wed, 18 Oct 1995 20:21:26 -0700 Received: (from moonhunt@localhost) by ns.easy.re.kr (8.6.12H1/8.6.9) id MAA01433; Thu, 19 Oct 1995 12:20:14 +0900 From: HyunSeog Ryu Message-Id: <199510190320.MAA01433@ns.easy.re.kr> Subject: Re: device number for watchdog board driver To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Thu, 19 Oct 1995 12:20:14 +1553003 (KST) Cc: hackers@freebsd.org In-Reply-To: <199510190245.TAA10415@rah.star-gate.com> from "Amancio Hasty Jr." at Oct 18, 95 07:45:02 pm X-Mailer: ELM [version 2.4 PL21-h4] Content-Type: text Content-Length: 1328 Sender: owner-hackers@freebsd.org Precedence: bulk > > > > Dumb question: is there a command which I can use to display all the majo > r > > > and minor devices and hopefully the name of the device > > > driver that the system knows about? > > You can refer /sys/i386/conf/devices.i386 for major number... > > Yes, I know about that lets assume that I visit a FreeBSD box and > that /sys is not there. Hmmm... Here is that content... # This file tells what major numbers the various possible swap devices have. # # $Id: devices.i386,v 1.8.4.1 1995/09/14 23:47:09 jkh Exp $ # wd 0 dk 1 fd 2 wt 3 sd 4 st 5 cd 6 mcd 7 vn 15 scd 16 pcd 17 wcd 19 od 20 > > > > But minor number ??? ;> > > And you can refer lsdev command also... > > Nice listing but there is no association between the nice output of > lsdev and /dev: And you can refer /dev/MAKEDEV shell script also... ;> From Hyunseog Ryu =============================================================================== Name : Hyunseog Ryu moonhunt@easy.re.kr Tel : +82-2-884-0174 http://www.easy.re.kr/~moonhunt Fax : +82-2-884-0175 :-) EASY research institute Tomorrow is another day... ;> 4th floor, 304-25, shinrim 10-dong For better world, cheers!!! Kwanak-gu, Seoul, 151-020, Korea :-D =============================================================================== From owner-freebsd-hackers Wed Oct 18 20:27:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA11675 for hackers-outgoing; Wed, 18 Oct 1995 20:27:11 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA11660 for ; Wed, 18 Oct 1995 20:27:06 -0700 Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id UAA29723 for ; Wed, 18 Oct 1995 20:25:58 -0700 Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id NAA14906; Thu, 19 Oct 1995 13:21:24 +1000 From: David Dawes Message-Id: <199510190321.NAA14906@rf900.physics.usyd.edu.au> Subject: Re: xterm dumps core To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Thu, 19 Oct 1995 13:21:24 +1000 (EST) Cc: hackers@freebsd.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 19, 95 05:56:10 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1090 Sender: owner-hackers@freebsd.org Precedence: bulk >In message <199510190237.MAA14718@rf900.physics.usyd.edu.au> David > Dawes writes: > >>>In message <199510180847.SAA12056@rf900.physics.usyd.edu.au> David >>> Dawes writes: >>> >>>>Does this mean that the default locale names have been changed in -current >>>>to include these underscores? On 2.0.5, they don't have them. If I do: >>> >>>Yes, locale names in current and stable conforms RFC 1700 (valid charset >>>names list registered by IANA). >>>ISO8859-1 is _invalid_ name. > >>I just checked a machine I have running a recent SNAP (951005), and it still >>uses the old names. Has this been changed in stable since then? > >It seems that you still have obsoleted names from previous versions. >You need to say "make distrib-dirs" in /usr/src/etc, remove >obsoleted dirs and re-build/install /usr/src/bin/{mklocale,colldef} and >/usr/src/share/timedef. I'm using to a clean install of the 2.1.0-951005-SNAP binary set, not one I built myself. It has only the old names, and not the new names. Is that SNAP incorrect in this regard? What will be in the 2.1.0 release? David From owner-freebsd-hackers Wed Oct 18 20:33:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA12894 for hackers-outgoing; Wed, 18 Oct 1995 20:33:01 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id UAA12884 for ; Wed, 18 Oct 1995 20:32:56 -0700 Received: by sequent.kiae.su id AA10465 (5.65.kiae-2 ); Thu, 19 Oct 1995 07:25:40 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 19 Oct 95 07:25:39 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id GAA00948; Thu, 19 Oct 1995 06:24:39 +0300 To: David Dawes Cc: hackers@freebsd.org References: <199510190257.MAA14837@rf900.physics.usyd.edu.au> In-Reply-To: <199510190257.MAA14837@rf900.physics.usyd.edu.au>; from David Dawes at Thu, 19 Oct 1995 12:57:58 +1000 (EST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 19 Oct 1995 06:24:39 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: Well, I have proper name & X locale installed, why xterm still Lines: 63 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2261 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510190257.MAA14837@rf900.physics.usyd.edu.au> David Dawes writes: >They are the ones I have installed (they are part of our current >alpha version of XFree86). >When I then do: > setenv ENABLE_STARTUP_LOCALE > setenv LANG ru_SU.KOI8-R >and start xterm, it starts up without any problems. >If I remove either of those lines from locale.dir or locale.alias >it dumps core (and dumps core rather than just ignoring a locale it >doesn't recognise only because the assumption that the initial locale >is "C" isn't true). >Perhaps you should send me your /usr/X11R6/lib/X11/locale directory. David, I just check all things that you mention, but it still fails. Can you send me your locale dir please? Since I have russian locale running normally, it will be best to test it here. Thanx for your help. I have two clues about it. 1) Does KOI8-R as registered name hardcoded somewhere inside X lib? (I suspect my 3.1.2 don't have it as registered name). 2) Does you have installed /usr/share/locale/ru_SU.KOI8-R/{LC_CTYPE,LC_COLLATE,LC_TIME}? (when I remove this dir, xterm stops core dump). BTW, could you please add following names list to current XFree locale.alias? (to be compatible with RFC 1700 and FreeBSD 2.1) da_DK.ISO_8859-1 da_DK.ISO8859-1 de_AT.ISO_8859-1 de_AT.ISO8859-1 de_CH.ISO_8859-1 de_CH.ISO8859-1 de_DE.ISO_8859-1 de_DE.ISO8859-1 en_AU.ISO_8859-1 en_AU.ISO8859-1 en_CA.ISO_8859-1 en_CA.ISO8859-1 en_GB.ISO_8859-1 en_GB.ISO8859-1 en_US.ISO_8859-1 en_US.ISO8859-1 es_ES.ISO_8859-1 es_ES.ISO8859-1 fi_FI.ISO_8859-1 fi_FI.ISO8859-1 fr_BE.ISO_8859-1 fr_BE.ISO8859-1 fr_CA.ISO_8859-1 fr_CA.ISO8859-1 fr_CH.ISO_8859-1 fr_CH.ISO8859-1 fr_FR.ISO_8859-1 fr_FR.ISO8859-1 is_IS.ISO_8859-1 is_IS.ISO8859-1 it_CH.ISO_8859-1 it_CH.ISO8859-1 it_IT.ISO_8859-1 it_IT.ISO8859-1 nl_BE.ISO_8859-1 nl_BE.ISO8859-1 nl_NL.ISO_8859-1 nl_NL.ISO8859-1 no_NO.ISO_8859-1 no_NO.ISO8859-1 pt_PT.ISO_8859-1 pt_PT.ISO8859-1 sv_SE.ISO_8859-1 sv_SE.ISO8859-1 -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Wed Oct 18 20:33:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA12975 for hackers-outgoing; Wed, 18 Oct 1995 20:33:34 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA12962 for ; Wed, 18 Oct 1995 20:33:31 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id UAA21719; Wed, 18 Oct 1995 20:31:44 -0700 From: Julian Elischer Message-Id: <199510190331.UAA21719@ref.tfs.com> Subject: Re: device number for watchdog board driver To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Wed, 18 Oct 1995 20:31:44 -0700 (PDT) Cc: moonhunt@easy.re.kr, hackers@freebsd.org In-Reply-To: <199510190245.TAA10415@rah.star-gate.com> from "Amancio Hasty Jr." at Oct 18, 95 07:45:02 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2298 Sender: owner-hackers@freebsd.org Precedence: bulk > > > Also not to mention that loadable modules are not listed... > > I was thinking more along the lines of : > > 25: sd1 at SCSI bus 0:6:0 (ready) (open) > 4, 65546 /dev/sd1 > 4, 8 /dev/sd1a > 4, 9 /dev/sd1b > .... this is what devfs is for with the added advantage that you can access the devices from there as well for an axample: freeway: {1} ls -lR /devs total 0 dr-xr-xr-x 4 root wheel 29 Oct 17 00:36 disks dr-xr-xr-x 2 root wheel 96 Oct 17 00:36 misc /devs/disks: total 0 dr-xr-xr-x 2 root wheel 16 Oct 17 00:36 floppy dr-xr-xr-x 2 root wheel 16 Oct 17 00:36 rfloppy /devs/disks/floppy: total 0 brw-r--r-- 2 root wheel 2, 0 Oct 17 00:36 fd0.1440 /devs/disks/rfloppy: total 0 crw-r--r-- 2 root wheel 9, 0 Oct 17 00:36 fd0.1440 /devs/misc: total 0 crw-r----- 2 root wheel 0, 0 Oct 17 00:36 console crw-r----- 2 root kmem 2, 14 Oct 17 00:36 io crw-r----- 2 root kmem 2, 1 Oct 17 00:36 kmem crw-r----- 2 root kmem 2, 0 Oct 17 00:36 mem crw-rw-rw- 2 root wheel 2, 2 Oct 17 00:36 null crw-r----- 2 root kmem 34, 0 Oct 17 00:36 pmem crw-r----- 2 root kmem 33, 0 Oct 17 00:36 tiga crw-rw-rw- 2 root wheel 2, 12 Oct 17 00:36 zero as an example.. pmem and tiga have no entries in conf.c they added their own entries dynamically and told devfs about it.. devfs reports where they ended up (apparently they slotted themselves in at 33 and 34) I need to add about 10 lines of code to each device driver to make this complete, but the one that is holding me back is the diskslice/disklabel code, which needs a rather more complicated interaction with devfs, and I haven't worked out what the best way of doing it yet is.. > > You see as more drivers and/or loadable modules get added to FreeBSD > it becomes rather nice to issue a single command to figure out what > is on the system. EXACTLY Why devfs is needed.. handles LKMS and other such things.. for example a device might go into debug mode when given a particular ioctl, and could create a debug device on the fly.. (for debug info to come out of or something) turning debug mode off again.. that debug device would dissappear again. (If you had it open you would end up holding a vnode to the deadfs) > > Enjoy, > Amancio > > > From owner-freebsd-hackers Wed Oct 18 20:37:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA13702 for hackers-outgoing; Wed, 18 Oct 1995 20:37:25 -0700 Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA13656 for ; Wed, 18 Oct 1995 20:37:04 -0700 Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id NAA14948; Thu, 19 Oct 1995 13:30:37 +1000 From: David Dawes Message-Id: <199510190330.NAA14948@rf900.physics.usyd.edu.au> Subject: Re: xterm dumps core To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Thu, 19 Oct 1995 13:30:36 +1000 (EST) Cc: hackers@freebsd.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 19, 95 05:13:22 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 907 Sender: owner-hackers@freebsd.org Precedence: bulk >>Andrey should think about the consequences of upsetting thousands of >>previously happy FreeBSD users when they discover that the X that they've >>been using just fine for a year or more on FreeBSD 2.0/2.0.5 no longer >>works, with problems ranging from xterm dumping core to compose processing >>no longer working. > >X shipped on the same CD as FreeBSD and it is newer that >2.0/2.0.5 variant, so upgrading recommended in this case. >I already make neccessary locale.alias additions. Does this imply that the XFree86 shipped with 2.1 will contain the new names in locale.alias? If so, please do not call it simply "XFree86 3.1.2" because that will lead to confusion with the definitive 3.1.2 version, and cause problems for someone who wants to upgrade their source to a new version with a future patch. Please make it clear that it is a version updated to include support for FreeBSD 2.1. David From owner-freebsd-hackers Wed Oct 18 21:01:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA17864 for hackers-outgoing; Wed, 18 Oct 1995 21:01:04 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA17849 for ; Wed, 18 Oct 1995 21:00:59 -0700 Received: by sequent.kiae.su id AA16039 (5.65.kiae-2 ); Thu, 19 Oct 1995 07:48:04 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 19 Oct 95 07:48:03 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id GAA01035; Thu, 19 Oct 1995 06:47:20 +0300 To: "Kaleb S. KEITHLEY" , Terry Lambert Cc: hackers@freefall.FreeBSD.org References: <199510190220.TAA01615@phaeton.artisoft.com> In-Reply-To: <199510190220.TAA01615@phaeton.artisoft.com>; from Terry Lambert at Wed, 18 Oct 1995 19:20:55 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 19 Oct 1995 06:47:19 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: xterm dumps core Lines: 22 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 929 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510190220.TAA01615@phaeton.artisoft.com> Terry Lambert writes: >What Andrey *might* be overlooking is when the X server is FreeBSD >and the client is one of the legacy systems. Well, that client uses old naming convention always present in locale.alias, so it will be backward compatible with X. I don't suggest to _replace_ old names by new ones, I suggest to _add_ new names. It can be not compatible with FreeBSD own locale, but such result even isn't expected. Imagine Sun's client with its usual LANG=iso_8859-1 (BTW, Sun use RFC 1700 compatible name!), FreeBSD locale does nothing, but X locale still works. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Wed Oct 18 21:01:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA17961 for hackers-outgoing; Wed, 18 Oct 1995 21:01:25 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA17949 ; Wed, 18 Oct 1995 21:01:21 -0700 Received: by sequent.kiae.su id AA16028 (5.65.kiae-2 ); Thu, 19 Oct 1995 07:48:00 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 19 Oct 95 07:48:00 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id GAA01004; Thu, 19 Oct 1995 06:33:44 +0300 To: David Dawes Cc: David Greenman , hackers@freebsd.org, "Jordan K. Hubbard" References: <199510190321.NAA14906@rf900.physics.usyd.edu.au> In-Reply-To: <199510190321.NAA14906@rf900.physics.usyd.edu.au>; from David Dawes at Thu, 19 Oct 1995 13:21:24 +1000 (EST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 19 Oct 1995 06:33:44 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: xterm dumps core Lines: 25 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1157 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510190321.NAA14906@rf900.physics.usyd.edu.au> David Dawes writes: >>>I just checked a machine I have running a recent SNAP (951005), and it still >>>uses the old names. Has this been changed in stable since then? >> >>It seems that you still have obsoleted names from previous versions. >>You need to say "make distrib-dirs" in /usr/src/etc, remove >>obsoleted dirs and re-build/install /usr/src/bin/{mklocale,colldef} and >>/usr/src/share/timedef. >I'm using to a clean install of the 2.1.0-951005-SNAP binary set, not >one I built myself. It has only the old names, and not the new names. >Is that SNAP incorrect in this regard? What will be in the 2.1.0 release? I don't involved in SNAPs build so can't answer this question... Maybe Jordan or David can? In any case I saw this changes commited to 2.1.0, maybe after this SNAP date... -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Wed Oct 18 21:01:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA18084 for hackers-outgoing; Wed, 18 Oct 1995 21:01:55 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA18072 ; Wed, 18 Oct 1995 21:01:51 -0700 Received: by sequent.kiae.su id AA17715 (5.65.kiae-2 ); Thu, 19 Oct 1995 07:59:11 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 19 Oct 95 07:59:11 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id GAA01094; Thu, 19 Oct 1995 06:56:56 +0300 To: David Dawes Cc: asami@freebsd.org, hackers@freebsd.org References: <199510190330.NAA14948@rf900.physics.usyd.edu.au> In-Reply-To: <199510190330.NAA14948@rf900.physics.usyd.edu.au>; from David Dawes at Thu, 19 Oct 1995 13:30:36 +1000 (EST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 19 Oct 1995 06:56:56 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: xterm dumps core Lines: 37 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1796 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510190330.NAA14948@rf900.physics.usyd.edu.au> David Dawes writes: >>>Andrey should think about the consequences of upsetting thousands of >>>previously happy FreeBSD users when they discover that the X that they've >>>been using just fine for a year or more on FreeBSD 2.0/2.0.5 no longer >>>works, with problems ranging from xterm dumping core to compose processing >>>no longer working. >> >>X shipped on the same CD as FreeBSD and it is newer that >>2.0/2.0.5 variant, so upgrading recommended in this case. >>I already make neccessary locale.alias additions. >Does this imply that the XFree86 shipped with 2.1 will contain the new >names in locale.alias? If so, please do not call it simply "XFree86 Small correction: not "new" but "additional" names, I mean that old names still present. Yes, after Satoshi apply my patch and rebuilds XFree. >3.1.2" because that will lead to confusion with the definitive 3.1.2 >version, and cause problems for someone who wants to upgrade their source >to a new version with a future patch. Please make it clear that it is >a version updated to include support for FreeBSD 2.1. Well, everything from ports area assumed to be tuned/configured/patched especially for FreeBSD and goes under original names. But I think nothing wrong happens, if patching fact will be specially mentioned as you want. /usr/ports/Xfree86/pkg/DESCR should be updated according to your proposal. Since Satoshi is our ports master, I pass this issue to him. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Wed Oct 18 21:06:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA18760 for hackers-outgoing; Wed, 18 Oct 1995 21:06:57 -0700 Received: from asstdc.scgt.oz.au (asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA18075 for ; Wed, 18 Oct 1995 21:01:53 -0700 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD-4.4) id NAA01958; Thu, 19 Oct 1995 13:56:48 +1000 From: michael butler Message-Id: <199510190356.NAA01958@asstdc.scgt.oz.au> Subject: Re: DNS question To: fenner@parc.xerox.com (Bill Fenner) Date: Thu, 19 Oct 1995 13:56:47 +1000 (EST) Cc: jdl@chromatic.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <95Oct18.154837pdt.177478@crevenia.parc.xerox.com> from "Bill Fenner" at Oct 18, 95 03:48:31 pm X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 11379 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Bill Fenner writes: > >Is there a way to reliably claim to do DNS for anything less than > >a full Class-C subnet? > The best way to do this is to have the person who is primary for > 166.1.199.in-addr.arpa insert records like: > jdl IN NS jdl.com. > 200 IN CNAME 200.jdl > 201 IN CNAME 201.jdl > 202 IN CNAME 202.jdl > ... > 207 IN CNAME 207.jdl > And then you can build a database for jdl.166.1.199.in-addr.arpa and you can > be authoritative. > I am sure that this is documented somewhere but can't figure out where. The > most recent time I heard it described was at the NANOG meeting a month or so > ago, and the person describing it said that people have been doing this for > years. As follows .. Network Working Group Havard Eidnes INTERNET-DRAFT SINTEF RUNIT draft-degroot-classless-inaddr-00.txt Geert Jan de Groot RIPE NCC May 1995 Classless in-addr.arpa delegation 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Should this draft end up being published as an RFC, then: This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 2. Introduction This document describes a way to do in-addr.arpa delegation on non- octet boundaries. The proposed method should thus remove one of the objections to do subnetting on non-octet boundaries but perhaps more significantly, make it possible to assign IP address space in smaller chunks than 24-bit prefixes without losing the ability to delegate authority for the corresponding in-addr.arpa mappings. The proposed method is fully compatible with the original DNS lookup mechanisms specified in [1], i.e. there is no need to modify the lookup algorithm used, and there should be no need to modify any software which does DNS lookups either. Eidnes, de Groot Expires 951124 [Page 1] INTERNET-DRAFT Classless in-addr.arpa delegation May 1995 3. Motivation With the proliferation of classless routing technology, it has become feasible to assign address space on non-octet boundaries. In case of a Very Small Organization with only a few hosts, assigning a full 24-bit prefix (what has traditionally been referred to as a ``class C network number'') often leads to inefficient address space utilization. One of the problems encountered when assigning a longer prefix (less address space) is that it seems impossible for such an organization to maintain its own reverse (``in-addr.arpa'') zone autonomously. If the reverse delegation problem is solved, perhaps the most important objection to assignment of longer prefixes to unrelated organizations can be removed. Let us assume we have assigned the address spaces to three different parties as follows: 192.0.2.0/25 to organization A 192.0.2.128/26 to organization B 192.0.2.192/26 to organization C In the classical approach, this would lead to a single zone like this: $ORIGIN 2.0.192.in-addr.arpa. ; 1 PTR host1.A.domain. 2 PTR host2.A.domain. 3 PTR host3.A.domain. ; 129 PTR host1.B.domain. 130 PTR host2.B.domain. 131 PTR host3.B.domain. ; 193 PTR host1.C.domain. 194 PTR host2.C.domain. 195 PTR host3.C.domain. The administration of this zone is problematic. Authority for this zone can only be delegated once, and this usually translates into ``this zone can only be administrated by one organization.'' The other organizations with address space which corresponds to entries in this zone would thus have to depend on another organization for their address to name translation. With the proposed method, this potential problem can be avoided. Eidnes, de Groot Expires 951124 [Page 2] INTERNET-DRAFT Classless in-addr.arpa delegation May 1995 4. Classless in-addr.arpa domain Since a single zone can only be delegated once we need more points to do delegation on to solve the problem above. These extra points of delegation can be introduced by extending the in-addr.arpa tree downwards, e.g. by using the first address in the corresponding address space as the first component in the name for the zones. For the problem described in the motivation section, the corresponding 4 zone files would look something like this (here shown with network masks and network names in the form specified in [2] as well): $ORIGIN 2.0.192.in-addr.arpa. @ IN SOA my-ns.my.domain. hostmaster.my.domain. ( ... ) ;... 0 NS ns.A.domain. 0 NS some.other.name.server. ; 128 NS ns.B.domain. 128 NS some.other.name.server.too. ; 192 NS ns.C.domain 192 NS some.other.third.name.server. ; 1 CNAME 1.0.2.0.192.in-addr.arpa. 2 CNAME 2.0.2.0.192.in-addr.arpa. 3 CNAME 3.0.2.0.192.in-addr.arpa. ; 129 CNAME 129.128.2.0.192.in-addr.arpa. 130 CNAME 130.128.2.0.192.in-addr.arpa. 131 CNAME 131.128.2.0.192.in-addr.arpa. ; 193 CNAME 193.192.2.0.192.in-addr.arpa. 194 CNAME 194.192.2.0.192.in-addr.arpa. 195 CNAME 195.192.2.0.192.in-addr.arpa. $ORIGIN 0.2.0.192.in-addr.arpa. @ IN SOA ns.A.domain. hostmaster.A.domain. ( ... ) @ NS ns.A.domain. @ NS some.other.name.server. @ PTR networkname.A.domain. @ A 255.255.255.128 ; 1 PTR host1.A.domain. 2 PTR host2.A.domain. 3 PTR host3.A.domain. Eidnes, de Groot Expires 951124 [Page 3] INTERNET-DRAFT Classless in-addr.arpa delegation May 1995 $ORIGIN 128.2.0.192.in-addr.arpa. @ IN SOA ns.B.domain. hostmaster.B.domain. ( ... ) @ NS ns.B.domain. @ NS some.other.name.server.too. @ PTR networkname.B.domain. @ A 255.255.255.192 ; 129 PTR host1.B.domain. 130 PTR host2.B.domain. 131 PTR host3.B.domain. $ORIGIN 192.2.0.192.in-addr.arpa. @ IN SOA ns.C.domain. hostmaster.C.domain. ( ... ) @ NS ns.C.domain @ NS some.other.third.name.server. @ PTR networkname.C.domain. @ A 255.255.255.192 ; 193 PTR host1.C.domain. 194 PTR host2.C.domain. 195 PTR host3.C.domain. An obvious alternative to using the first address in the corresponding address space to name the new zones is simply to use some other (non-numeric) name. It is of course also possible to point to an entirely different part of the DNS tree (outside of the in-addr.arpa tree). This approach makes it necessary to install approximately 256 CNAME records in the parent zone more or less permanently for each size-256 chunk split up this way. Some people might view this as ugly; we will not argue that particular point. It is however quite easy to automatically generate the CNAME resource records in the parent zone once and for all, if the way the address space is partitioned is known. The advantage of this approach over the other proposed approaches for dealing with this problem is that there should be no need to modify any already-deployed software. In particular, the lookup mechanism in the DNS does not have to be modified to accommodate this splitting of the responsibility for the IPv4 address to name translation on ``non-dot'' boundaries. This technique has been in use for several years in at least one installation, apparently with no ill effects. Eidnes, de Groot Expires 951124 [Page 4] INTERNET-DRAFT Classless in-addr.arpa delegation May 1995 5. References [1] P. Mockapetris, ``Domain Names - Concepts and Facilities'', RFC1034, ISI, November 1987. [2] P. Mockapetris, ``DNS Encoding of Network Names and Other Types'', RFC1101, ISI, April 1989. 6. Security Considerations Security considerations are not discussed in this memo. 7. Conclusion The suggested scheme gives more flexibility in delegating authority in the in-addr.arpa domain, thus making it possible to assign address space more efficiently without losing the ability to delegate the DNS authority over the corresponding address to name mappings. 8. Acknowledgments Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp-ip.domains some time ago. Alan Barrett , Sam Wilson , and Paul Vixie provided valuable comments on the newsgroup. We would like to thank Eric Wassenaar of NIKHEF , David Kessens , Daniel Karrenberg , Paul Vixie , and Glen A. Herrmannsfeldt for their review and constructive comments. Eidnes, de Groot Expires 951124 [Page 5] INTERNET-DRAFT Classless in-addr.arpa delegation May 1995 9. Author's Addresses Havard Eidnes SINTEF RUNIT N-7034 Trondheim Norway Phone: +73 59 44 68 Fax: +73 59 17 00 Email: Havard.Eidnes@runit.sintef.no Geert Jan de Groot RIPE Network Coordination Centre Kruislaan 409 1098 SJ Amsterdam, the Netherlands Phone: +31 20 592 5065 Fax: +31 20 592 5090 Email: GeertJan.deGroot@ripe.net Eidnes, de Groot Expires 951124 [Page 6] From owner-freebsd-hackers Wed Oct 18 21:16:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA20740 for hackers-outgoing; Wed, 18 Oct 1995 21:16:59 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA20716 for ; Wed, 18 Oct 1995 21:16:53 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id VAA10948; Wed, 18 Oct 1995 21:15:28 -0700 Message-Id: <199510190415.VAA10948@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Julian Elischer cc: moonhunt@easy.re.kr, hackers@freebsd.org Subject: Re: device number for watchdog board driver In-reply-to: Your message of "Wed, 18 Oct 1995 20:31:44 PDT." <199510190331.UAA21719@ref.tfs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 21:15:27 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk Now, if we could access this information along with a textual description of what the driver is supposed to do,version number of the driver and access this information via snmp we will be all set :) You see then we will have a generic interface to access the information not just locally but remotely from *different* machines. I believed that there is a mib interface for sysctl so we could use it as an example to export the driver information . Enjoy, Amancio >>> Julian Elischer said: > > > > > > Also not to mention that loadable modules are not listed... > > > > I was thinking more along the lines of : > > > > 25: sd1 at SCSI bus 0:6:0 (ready) (open) > > 4, 65546 /dev/sd1 > > 4, 8 /dev/sd1a > > 4, 9 /dev/sd1b > > .... > this is what devfs is for > with the added advantage that you can access the devices from there as well > for an axample: > freeway: {1} ls -lR /devs > total 0 > dr-xr-xr-x 4 root wheel 29 Oct 17 00:36 disks > dr-xr-xr-x 2 root wheel 96 Oct 17 00:36 misc > > /devs/disks: > total 0 > dr-xr-xr-x 2 root wheel 16 Oct 17 00:36 floppy > dr-xr-xr-x 2 root wheel 16 Oct 17 00:36 rfloppy > > /devs/disks/floppy: > total 0 > brw-r--r-- 2 root wheel 2, 0 Oct 17 00:36 fd0.1440 > > /devs/disks/rfloppy: > total 0 > crw-r--r-- 2 root wheel 9, 0 Oct 17 00:36 fd0.1440 > > /devs/misc: > total 0 > crw-r----- 2 root wheel 0, 0 Oct 17 00:36 console > crw-r----- 2 root kmem 2, 14 Oct 17 00:36 io > crw-r----- 2 root kmem 2, 1 Oct 17 00:36 kmem > crw-r----- 2 root kmem 2, 0 Oct 17 00:36 mem > crw-rw-rw- 2 root wheel 2, 2 Oct 17 00:36 null > crw-r----- 2 root kmem 34, 0 Oct 17 00:36 pmem > crw-r----- 2 root kmem 33, 0 Oct 17 00:36 tiga > crw-rw-rw- 2 root wheel 2, 12 Oct 17 00:36 zero > > as an example.. pmem and tiga > have no entries in conf.c > they added their own entries dynamically > and told devfs about it.. > devfs reports where they ended up (apparently they slotted themselves > in at 33 and 34) > > > I need to add about 10 lines of code to each device driver to make this > complete, but the one that is holding me back is the diskslice/disklabel > code, which needs a rather more complicated interaction with devfs, > and I haven't worked out what the best way of doing it yet is.. > > > > > You see as more drivers and/or loadable modules get added to FreeBSD > > it becomes rather nice to issue a single command to figure out what > > is on the system. > EXACTLY Why devfs is needed.. handles LKMS and other such things.. > for example a device might go into debug mode when given > a particular ioctl, and could create a debug device > on the fly.. (for debug info to come out of or something) > turning debug mode off again.. that debug device would dissappear again. > (If you had it open you would end up holding a vnode to the deadfs) > > > > > > > Enjoy, > > Amancio > > > > > > > > From owner-freebsd-hackers Wed Oct 18 21:24:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA21891 for hackers-outgoing; Wed, 18 Oct 1995 21:24:27 -0700 Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA21850 ; Wed, 18 Oct 1995 21:23:58 -0700 Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id OAA15359; Thu, 19 Oct 1995 14:23:26 +1000 From: David Dawes Message-Id: <199510190423.OAA15359@rf900.physics.usyd.edu.au> Subject: Re: xterm dumps core To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Thu, 19 Oct 1995 14:23:26 +1000 (EST) Cc: asami@freebsd.org, hackers@freebsd.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 19, 95 06:56:56 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1598 Sender: owner-hackers@freebsd.org Precedence: bulk >>>>Andrey should think about the consequences of upsetting thousands of >>>>previously happy FreeBSD users when they discover that the X that they've >>>>been using just fine for a year or more on FreeBSD 2.0/2.0.5 no longer >>>>works, with problems ranging from xterm dumping core to compose processing >>>>no longer working. >>> >>>X shipped on the same CD as FreeBSD and it is newer that >>>2.0/2.0.5 variant, so upgrading recommended in this case. >>>I already make neccessary locale.alias additions. > >>Does this imply that the XFree86 shipped with 2.1 will contain the new >>names in locale.alias? If so, please do not call it simply "XFree86 > >Small correction: not "new" but "additional" names, I mean >that old names still present. >Yes, after Satoshi apply my patch and rebuilds XFree. > >>3.1.2" because that will lead to confusion with the definitive 3.1.2 >>version, and cause problems for someone who wants to upgrade their source >>to a new version with a future patch. Please make it clear that it is >>a version updated to include support for FreeBSD 2.1. > >Well, everything from ports area assumed to be tuned/configured/patched >especially for FreeBSD and goes under original names. But I think >nothing wrong happens, if patching fact will be specially mentioned >as you want. /usr/ports/Xfree86/pkg/DESCR should be updated >according to your proposal. Since Satoshi is our ports master, I pass this >issue to him. If it is distributed as the standard source + patches which get applied at build time, then fine. I'm not really worried about the run-time set. David From owner-freebsd-hackers Wed Oct 18 22:02:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA27864 for hackers-outgoing; Wed, 18 Oct 1995 22:02:08 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA27857 for ; Wed, 18 Oct 1995 22:02:03 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id XAA12151; Wed, 18 Oct 1995 23:04:22 -0600 Date: Wed, 18 Oct 1995 23:04:22 -0600 From: Nate Williams Message-Id: <199510190504.XAA12151@rocky.sri.MT.net> To: hackers@FreeBSD.org Subject: Wow! Sender: owner-hackers@FreeBSD.org Precedence: bulk I'm getting ready to take-down my 2.0R system and upgrade it to 2.1, so I started looking through some of my logfiles. Here's an intersting note: I've got my internet connection setup to auto-dial my office if/when the link goes down. I power-cycled the modem this evening since I noticed it was starting to get sluggish (I finally had some time to do some Surfing tonight). Unfortunately, my USR doesn't re-train back up if the line gets bad. The cool things is that I noticed that the last time I had to dial work due to a modem carrier drop was 28 days ago, and that was because there was a power failure at work. Sep 20 14:00:51 trout chat[15242]: send (??????) Oct 18 22:49:25 trout chat[10025]: abort on (NO CARRIER) This is on a standard POTS line in Montana with 2 USR-28.8K Sportsters at both ends. Pretty amazing that the line hasn't went down in the entire months time except when I shut it down. Next, here are the stats from my box: trout:/usr/user/nate/Mail % uname -a FreeBSD trout.sri.MT.net 2.0-RELEASE FreeBSD 2.0-RELEASE #0: \ Fri Mar 31 22:08:04 MST 1995 \ root@trout.sri.MT.net:/usr/src/sys/compile/TROUT1 i386 trout:/usr/user/nate/Mail % uptime 10:55PM up 67 days, 5:58, 2 users, load averages: 0.19, 0.21, 0.15 This box has been on the Internet the entire time, and every night I do a sup to update the bits from freefall and update my tree. I've done tons of builds, tests, and when I have company they use NetScape to 'Surf the Web' on this box. It isn't ftp.cdrom.com, but it gets quite a beating for a single-user system. It's been rock-solid (even though I'm running 2.0R with minor tweaks by me) and I *hate* to upgrade it, but I want some of the new features of 2.1 including the newer VM stuff, plus all the fixes. Kudos to all of those involved. I still have a hard-time imagining I don't have to pay for this, and that it runs so much better than the SCO boxes we pay monster bucks at work with. Thanks folks for all of the hard work! Nate From owner-freebsd-hackers Wed Oct 18 22:16:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA29916 for hackers-outgoing; Wed, 18 Oct 1995 22:16:08 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id WAA29898 ; Wed, 18 Oct 1995 22:16:01 -0700 Received: by sequent.kiae.su id AA29215 (5.65.kiae-2 ); Thu, 19 Oct 1995 09:03:37 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 19 Oct 95 09:03:36 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id IAA01399; Thu, 19 Oct 1995 08:00:35 +0300 To: David Dawes Cc: asami@freebsd.org, hackers@freebsd.org References: <199510190423.OAA15359@rf900.physics.usyd.edu.au> In-Reply-To: <199510190423.OAA15359@rf900.physics.usyd.edu.au>; from David Dawes at Thu, 19 Oct 1995 14:23:26 +1000 (EST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 19 Oct 1995 08:00:35 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: xterm dumps core Lines: 16 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 709 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510190423.OAA15359@rf900.physics.usyd.edu.au> David Dawes writes: >If it is distributed as the standard source + patches which get applied >at build time, then fine. I'm not really worried about the run-time set. Yes, it is distributed as standard tarred source and my patch applied even at install time. But it is distributed as ready-to-run FreeBSD binaries set too with my patch imbedded. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Wed Oct 18 22:33:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA03385 for hackers-outgoing; Wed, 18 Oct 1995 22:33:42 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA03366 ; Wed, 18 Oct 1995 22:33:38 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id WAA02385; Wed, 18 Oct 1995 22:33:21 -0700 Date: Wed, 18 Oct 1995 22:33:21 -0700 Message-Id: <199510190533.WAA02385@silvia.HIP.Berkeley.EDU> To: ache@astral.msk.su CC: dawes@rf900.physics.usyd.edu.au, davidg@freebsd.org, hackers@freebsd.org, jkh@freefall.FreeBSD.org In-reply-to: Subject: Re: xterm dumps core From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-hackers@freebsd.org Precedence: bulk * >I'm using to a clean install of the 2.1.0-951005-SNAP binary set, not * >one I built myself. It has only the old names, and not the new names. * >Is that SNAP incorrect in this regard? What will be in the 2.1.0 release? * * I don't involved in SNAPs build so can't answer this question... * Maybe Jordan or David can? Well I can. Jordan and David are too busy to read this. :) * In any case I saw this changes commited to 2.1.0, maybe after this SNAP * date... You are right, it went in after the 1005 snap. Satoshi From owner-freebsd-hackers Wed Oct 18 22:40:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA04863 for hackers-outgoing; Wed, 18 Oct 1995 22:40:40 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA04842 for ; Wed, 18 Oct 1995 22:40:34 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id WAA17849; Wed, 18 Oct 1995 22:40:20 -0700 To: multimedia@rah.star-gate.com cc: hackers@freebsd.org Subject: Bragging rights.. Date: Wed, 18 Oct 1995 22:40:19 -0700 Message-ID: <17846.814081219@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk Well, this is half me needing to tell *somebody* and half actually being informative since some of the people on this list have wanted to test various FreeBSD audio/video apps with me and were frustrated that I only had that dinkly little V.34 modem. Well no more! I have now joined Amancio in the extended peni^H^H^H^Hbandwidth ISDN club! :-) I've implemented it in the cheapest way possible (no fancy pipeline solutions used here :-): A TA is hooked to a normal FreeBSD box with a standard 16550 serial port on both ends. I'm using the ADTRAN TAs - not the dirt-cheapest or the highest tech, but they're the only ones that did *everything* I wanted and did it *now*. Talk to Motorola and it's "yeah, you can have async bonding in a PROM upgrade RSN - we promise!" My FreeBSD gateway machine makes an ISDN call to the other end and does a standard SLIP login. The other route I could have gone cheaply would have been a pair of ISDN plug-in cards, but it doesn't look like we have our act together in the states anywhere near as well as the Germans do.. The only practical ISDN card solutions I could find were German ones, and I didn't want to play with trying to adapt a EURO-ISDN solution to my U.S. line.. :-) If I ever manage to hook something up with Digiboard, however, this may change. We can always sell the TAs! :-) So anyway, it works really well. The service is CENTREX ISDN between my house and Walnut Creek and doesn't cost me anything per-minute, meaning I can leave it up 24 hours a day (and will). I'm actually plugged directly into a serial port on freefall - it was the only machine in our entire machine room WITH a serial card plugged into it at the time! :) I get around 10.2K/sec with compressed tar files, which is actually pretty amazing (read: impossible? :) considering that i'm only running *async* bonding for 115.2Kbaud with all the start and stop bit overhead as opposed to the full 128Kb data rate I could get if I was running full sync serial. Since I'm in the same PacBell central office as the other end (couldn't do CENTREX otherwise) I can get the full 64K/B-channel. Verdict: It's not bad! Serial I/O overhead on freefall appears to be fairly negligible (I was worried about that for awhile) and I've gone almost 4x my previous V.34 communications rate.. I'd recommend it to anyone! :) I'm impressed that this was also managed with only two TAs and a pair of FreeBSD boxes - no other custom hardware of any sort was required. I can see a lot of 386 boxes coming back to service as dedicated ISDN routers in the next few years.. :-) Now if I can just get my hands on a pair of ISDN cards to get that full pipe.. [he gazes off into the distance..] Jordan From owner-freebsd-hackers Wed Oct 18 22:43:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA05510 for hackers-outgoing; Wed, 18 Oct 1995 22:43:32 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA05466 ; Wed, 18 Oct 1995 22:43:23 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id WAA02419; Wed, 18 Oct 1995 22:41:58 -0700 Date: Wed, 18 Oct 1995 22:41:58 -0700 Message-Id: <199510190541.WAA02419@silvia.HIP.Berkeley.EDU> To: ache@astral.msk.su CC: dawes@rf900.physics.usyd.edu.au, hackers@freebsd.org, rich@freebsd.org, jmz@freebsd.org In-reply-to: Subject: Re: xterm dumps core From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-hackers@freebsd.org Precedence: bulk Gosh, so many mails on this topic, but I'll reply to this one. * >If it is distributed as the standard source + patches which get applied * >at build time, then fine. I'm not really worried about the run-time set. * * Yes, it is distributed as standard tarred source and my patch applied * even at install time. But it is distributed as ready-to-run FreeBSD * binaries set too with my patch imbedded. This is not correct. As far as I know, Rich Murphey (who is getting this mail via CC:), who is responsible for building XFree86 binaries for the releases, is not using /usr/ports/x11/XFree86. The latter was invented and maintained by Jean-Marc Zucconi. In particular, if you build from the one in ports, you won't get many of the programs on the contrib tape (most notably xload and xeyes). I'm not sure what I should do on this, can you (Andrey) check with Rich and Jean-Marc and make sure we are all in sync? Or you guys (Rich and Jean-Marc) can just reply to this mail. Satoshi From owner-freebsd-hackers Wed Oct 18 22:51:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA07066 for hackers-outgoing; Wed, 18 Oct 1995 22:51:20 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA07006 for ; Wed, 18 Oct 1995 22:50:59 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id PAA14426 for hackers@freebsd.org; Thu, 19 Oct 1995 15:55:24 +0930 From: Michael Smith Message-Id: <199510190625.PAA14426@genesis.atrad.adelaide.edu.au> Subject: Re: Wow! To: hackers@freebsd.org Date: Thu, 19 Oct 1995 15:55:23 +0930 (CST) In-Reply-To: <199510190504.XAA12151@rocky.sri.MT.net> from "Nate Williams" at Oct 18, 95 11:04:22 pm Content-Type: text Content-Length: 3184 Sender: owner-hackers@freebsd.org Precedence: bulk Nate Williams stands accused of saying: > trout:/usr/user/nate/Mail % uptime > 10:55PM up 67 days, 5:58, 2 users, load averages: 0.19, 0.21, 0.15 > > This box has been on the Internet the entire time, and every night I do > a sup to update the bits from freefall and update my tree. I've done > tons of builds, tests, and when I have company they use NetScape to > 'Surf the Web' on this box. It isn't ftp.cdrom.com, but it gets quite a > beating for a single-user system. > > It's been rock-solid (even though I'm running 2.0R with minor tweaks by > me) and I *hate* to upgrade it, but I want some of the new features of > 2.1 including the newer VM stuff, plus all the fixes. Not to knock Nate in the slightest, but simply to add my weight to his congratulations, I have two stories to tell. - the first was the recent decommissioning of spam.apana.org.au, a stock 2.0 system, and the machine I used as a mail and ftp server at home. With 5M of memory and never enough disk, it routed my not-terribly-busy SLIP link and served 2.0 and later 2.0.5 to large numbers of up-and-coming APANA FreeBSD'ers. Uptime when shut off was a little over two months, and only that due to a power failure. - the second is our organisation's mail server, router, FTP server, xdm server, socks proxy, you name it. On an insanely busy ethernet, it provides serial ports for our dialin SLIP links, serves several Sun 3/60s being used as Xterms, provides fileservice to a small group of Workgroups machines using Samba, has about twenty shell accounts for mail users, runs the only SCSI bus suitable for "enterprise" backups, runs a socks proxy for several internal 10.* networks, and has this to say about its uptime : 3:46PM up 125 days, 22:06, 3 users, load averages: 0.13, 0.52, 1.02 (For about a month in there there were a couple of runaway vi processes that pushed the load average up to 2+ continually, and there's an autoconf fragment in there that's locked on something mmaped, but I can't be bothered rebooting for such a trifle. We lost an NFS mount for a week or so as well, but nothing broke.) Needless to say, this is a 2.0R system as well 8) Sometime soon (like when I get the time 8) it will go to 2.1 in order to handle PPP logins and perhaps grow some more disk at the same time. In the same period, the Suns have never stayed up for more than a few weeks, offering an excellent contrast 8) > Kudos to all of those involved. I still have a hard-time imagining I > don't have to pay for this, and that it runs so much better than the SCO > boxes we pay monster bucks at work with. Spot on. I know everyone's having a hard time right now, but hopefully being thanked will at least lower the blood pressure a tad 8) > Thanks folks for all of the hard work! Amen! > Nate -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Wed Oct 18 23:03:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA09405 for hackers-outgoing; Wed, 18 Oct 1995 23:03:27 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA09396 for ; Wed, 18 Oct 1995 23:03:24 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id XAA11705; Wed, 18 Oct 1995 23:02:45 -0700 Message-Id: <199510190602.XAA11705@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: "Jordan K. Hubbard" cc: multimedia@rah.star-gate.com, hackers@freebsd.org Subject: Re: Bragging rights.. In-reply-to: Your message of "Wed, 18 Oct 1995 22:40:19 PDT." <17846.814081219@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 23:02:44 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk Hey, Send mail to Jim Lowe for a demo of his matrox meteor video capture board with nv :) And if he has the gus max installed you will be able to chat him :) Cheers, Amancio From owner-freebsd-hackers Wed Oct 18 23:23:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA11443 for hackers-outgoing; Wed, 18 Oct 1995 23:23:30 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA11437 for ; Wed, 18 Oct 1995 23:23:27 -0700 Received: from psychotic.communica.com.au (root@gw.communica.com.au [203.8.94.161]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id XAA00566 for ; Wed, 18 Oct 1995 23:22:21 -0700 Received: from communica.com.au (newton@frenzy [192.82.222.1]) by psychotic.communica.com.au (8.6.12/8.6.9) with SMTP id PAA00759; Thu, 19 Oct 1995 15:44:11 +0930 Received: by communica.com.au (4.1/SMI-4.1) id AA17711; Thu, 19 Oct 95 15:40:47 CST From: newton@communica.com.au (Mark Newton) Message-Id: <9510190610.AA17711@communica.com.au> Subject: Re: Wow! To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Thu, 19 Oct 1995 15:40:47 +0930 (CST) Cc: hackers@freebsd.org In-Reply-To: <199510190625.PAA14426@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 19, 95 03:55:23 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 459 Sender: owner-hackers@freebsd.org Precedence: bulk Michael Smith wrote: > 3:46PM up 125 days, 22:06, 3 users, load averages: 0.13, 0.52, 1.02 ns.apana.org.au, the primary nameserver for the Australian Public Access Network Association, has been up for over 160 days (2.0R). - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-373-2523 Communica Systems WWW: http://www.communica.com.au From owner-freebsd-hackers Wed Oct 18 23:56:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA12267 for hackers-outgoing; Wed, 18 Oct 1995 23:56:10 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA12259 ; Wed, 18 Oct 1995 23:56:03 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA01589; Thu, 19 Oct 1995 16:48:10 +1000 Date: Thu, 19 Oct 1995 16:48:10 +1000 From: Bruce Evans Message-Id: <199510190648.QAA01589@godzilla.zeta.org.au> To: terry@lambert.org, wollman@lcs.mit.edu Subject: Re: getdtablesize() broken? Cc: bakul@netcom.com, bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >> > ] #define ARG_MAX 65536 /* max bytes for an exec function */ >> >> > Type: Bogus. >> >> Type: POSIX. Type: Bogus. >> BZZZZT! Wrong, but thanks for playing. You can ask David or John >> about the memory-fragmentation issues which mandate the use of a Defining it makes it part of the ABI and inhibits future changes such as changing it to another fixed value or solving the memory fragmentation problems and making the limit indeterminate (POSIX 2.8.4 says it shall not be defined if it is indeterminate). Few programs use ARG_MAX, but those that do may break unnecessarily if it is changed. The limit should also be OS-dependent to support emulation of bogus definitions of it in other OS's. E.g., in Linux it is 128K, so Linux programs that rely on it may break. Both Linux and FreeBSD should leave it undefined so that applications are forced to use sysconf() if they want to know about it. The emulation support for Linux would then be trivial (just return the FreeBSD limit is sysconf()). >> > ] #define CHILD_MAX 40 /* max simultaneous processes */ >> >> > Type: Administrative (compile time override) >> >> Type: Bogus but POSIX. Type: Bogus (fails POSIX standards tests). This is another POSIX limit that shall be left undefined if its value is indeterminate. Its value is indeterminate because it may be changed by setrlimit(). This limit is sometimes bogusly redefined in kernel config files without changing its value in the . Then the advertised value is wrong even in the default case. (the kernel just uses the redefined value for the default rlimit, so the effect is the same as if all programs started with a setrlimit()). >> >> > Required by: The ability for a user program to fork(2) the system to >> > death. >> >> BZZZZT! This value should be modifiable at run time. (It isn't yet.) BZZZZT! :-) The maximum number of child processes is modifiable at runtime (using setrlimit()) and sysconf() correctly returns the modified value. >> > ] #define LINK_MAX 32767 /* max file link count */ >> > Type: Pragmatic >> Type: POSIX. Type: Bogus. This is another POSIX limit that shall be left undefined if its value is indeterminate. Its value is indeterminate because it depends on the file system. File systems and sysconf() handle it more or less correctly. >> > ] #define MAX_CANON 255 /* max bytes in term canon input line */ >> > Type: Bogus >> Type: POSIX. Type: Bogus. There is a related limit TTYHOG whose value (1024) is nowhere near the advertised limit. Defining the limit correctly would make it part of the ABI and interfere with future improvements, as above. Fortunarely, this limit is even less useful than ARG_MAX, so perhaps nothing depends on it. >> > ] #define NGROUPS_MAX 16 /* max supplemental group id's */ >> > Type: Standard (Interoperability, Legacy) >> > Required by: NFS, YP >> > Reason: Excess groups are truncated by the NFS external ID >> > representation mechanism. In point of fact, this >> > limit should be 8 to ensure interoperability with >> > older SVR3/SVR4 systems. >> >> No, the NFS and RPC code have their own kluges to deal with broken >> systems. >You mean that they should. Try mounting an SVR4.0.2 NFS volume from a >BSD system, and then accessing it from a credential with > 8 groups. Unfortunately fixing limits in FreeBSD (by making them indeterminate) won't affect compatibility. >> > ] #define OPEN_MAX 64 /* max open files per process */ >> > Type: Bogus >> Type: POSIX. Type: Bogus. S Same as for CHILD_MAX. >> > ] #define PIPE_BUF 512 /* max bytes for atomic pipe writes */ >> > Type: Bogus >> Type: POSIX. Type: Bogus. A pain in the ABI, as above. Under Linux, PIPE_BUF is 4095. If the limit is actually 512 under FreeBSD, then Linux programs that expect to write 4095 atomically to pipes can't be emulated properly. >[ ... BC_ * ... ] >> > Type: Bogus >> >> Type: POSIX. >> >> > Required by: A user space program >> >> Required by: IEEE-CS technical committee P1003.1. >> >> Any user-space program that executes `bc' to do arithmetic, or uses >> the LC_COLLATE localization support, or executes `expr' to do >> arithmetic. >Yetch. >Revised-Type: Gross, but POSIX [a-zA-Z]etch. Interferes with ABI compatibility at the library level. Fewer problems with emulation because other OS's have their own libraries. Summary: 1,$s/^Type:.*/Type: Bogus/ Bruce From owner-freebsd-hackers Thu Oct 19 00:09:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA12599 for hackers-outgoing; Thu, 19 Oct 1995 00:09:32 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA12594 for ; Thu, 19 Oct 1995 00:09:30 -0700 Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id AAA18885; Thu, 19 Oct 1995 00:07:59 -0700 Message-ID: <3085F94F.13776BA0@FreeBSD.org> Date: Thu, 19 Oct 1995 00:07:59 -0700 From: "Jordan K. Hubbard" X-Mailer: Mozilla 2.0b1 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: Joao Carlos Mendes Luis CC: supervisor@alb.asctmd.com, hackers@FreeBSD.org, jhay@mikom.csir.co.za Subject: Re: IPX feedback request -Reply References: <199510182032.SAA19360@gaia.coppe.ufrj.br> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk Joao Carlos Mendes Luis wrote: > I can just think of the following: > 1) Routing Netware networks. This should be made by a daemon > .. > 2) Mounting NetWare disks. This is really a problem. How to convert > .. > 3) Print Services. A netware aware lpd would be useful. Most And the irony is that most people won't show much interest in IPX support for FreeBSD *until* these features appear. There's a "knee" here where IPX is only going to be of interest to a very small set of people until the framework is in place to support the rest. Those doing the development are just going to live with that, I guess! :-( -- Jordan From owner-freebsd-hackers Thu Oct 19 00:40:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA13221 for hackers-outgoing; Thu, 19 Oct 1995 00:40:14 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA13215 for ; Thu, 19 Oct 1995 00:40:11 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id AAA27835; Thu, 19 Oct 1995 00:40:08 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id AAA29673; Thu, 19 Oct 1995 00:35:29 -0700 Message-Id: <199510190735.AAA29673@corbin.Root.COM> To: David Dawes cc: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=), hackers@freebsd.org Subject: Re: xterm dumps core In-reply-to: Your message of "Thu, 19 Oct 95 13:21:24 +1000." <199510190321.NAA14906@rf900.physics.usyd.edu.au> From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 19 Oct 1995 00:35:27 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >>>>names list registered by IANA). >>>>ISO8859-1 is _invalid_ name. >> >>>I just checked a machine I have running a recent SNAP (951005), and it still >>>uses the old names. Has this been changed in stable since then? >> >>It seems that you still have obsoleted names from previous versions. >>You need to say "make distrib-dirs" in /usr/src/etc, remove >>obsoleted dirs and re-build/install /usr/src/bin/{mklocale,colldef} and >>/usr/src/share/timedef. > >I'm using to a clean install of the 2.1.0-951005-SNAP binary set, not >one I built myself. It has only the old names, and not the new names. >Is that SNAP incorrect in this regard? What will be in the 2.1.0 release? Yes, I was forced to bring in the RFC1170 name changes because of compatibility issues with our ports tree. This was done recently (10 days ago or so). -DG From owner-freebsd-hackers Thu Oct 19 00:59:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA13706 for hackers-outgoing; Thu, 19 Oct 1995 00:59:38 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA13701 ; Thu, 19 Oct 1995 00:59:35 -0700 Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id AAA19100; Thu, 19 Oct 1995 00:58:50 -0700 Message-ID: <3086053A.2577A1CC@FreeBSD.org> Date: Thu, 19 Oct 1995 00:58:50 -0700 From: "Jordan K. Hubbard" X-Mailer: Mozilla 2.0b1 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: davidg@Root.COM CC: Terry Lambert , "Garrett A. Wollman" , bde@zeta.org.au, bakul@netcom.com, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? References: <199510182230.PAA29572@corbin.Root.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk > >> BZZZZT! Wrong, but thanks for playing. You can ask David or John > >BZZZZT! Replace the enviornment with logical names and hang the > BZZZZT! Not if you want argv[] to work. We're not talking about just Why am I reminded of angry bees, arguing inside the hive? :-) -- Jordan From owner-freebsd-hackers Thu Oct 19 01:06:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA14133 for hackers-outgoing; Thu, 19 Oct 1995 01:06:26 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA14126 for ; Thu, 19 Oct 1995 01:06:21 -0700 Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id BAA19153; Thu, 19 Oct 1995 01:05:53 -0700 Message-ID: <308606E1.75D1B@FreeBSD.org> Date: Thu, 19 Oct 1995 01:05:53 -0700 From: "Jordan K. Hubbard" X-Mailer: Mozilla 2.0b1 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: "Eric L. Hernes" CC: hackers@FreeBSD.org Subject: Re: apache's knob in /etc/sysconfig References: <199510181709.MAA12192@jake.lodgenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk Thanks, fixed! -- Jordan From owner-freebsd-hackers Thu Oct 19 01:47:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA15023 for hackers-outgoing; Thu, 19 Oct 1995 01:47:35 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA15013 for ; Thu, 19 Oct 1995 01:46:56 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA07267; Thu, 19 Oct 1995 09:46:29 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA20664; Thu, 19 Oct 1995 09:46:29 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA02775; Thu, 19 Oct 1995 08:32:51 +0100 From: J Wunsch Message-Id: <199510190732.IAA02775@uriah.heep.sax.de> Subject: Re: device number for watchdog board driver To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Thu, 19 Oct 1995 08:32:51 +0100 (MET) Cc: terry@lambert.org, freebsd-hackers@FreeBSD.ORG Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510190053.RAA09347@rah.star-gate.com> from "Amancio Hasty Jr." at Oct 18, 95 05:53:21 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 591 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk As Amancio Hasty Jr. wrote: > > Nope, > > I was hoping for something along the lines of sysctl which will tell > me which devices the system things that it has in the *running kernel* > > sysctl -listdevices ?? or a functionally equivalent command. Interesting. In order to answer your question, i typed "dev", and then hit TAB (in tcsh). "dev_mkdb devmenue" was the answer. Ok, "m", another TAB -- mucho surprised! :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Oct 19 01:49:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA15152 for hackers-outgoing; Thu, 19 Oct 1995 01:49:28 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA15145 for ; Thu, 19 Oct 1995 01:49:19 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA07275; Thu, 19 Oct 1995 09:46:37 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA20666; Thu, 19 Oct 1995 09:46:37 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id JAA03004; Thu, 19 Oct 1995 09:34:24 +0100 From: J Wunsch Message-Id: <199510190834.JAA03004@uriah.heep.sax.de> Subject: Re: FreeBSD Kernel Development... To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Thu, 19 Oct 1995 09:34:23 +0100 (MET) Cc: crosswjo@hp-pcd.cv.hp.com Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510190303.MAA13953@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 19, 95 12:33:47 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 542 Sender: owner-hackers@freebsd.org Precedence: bulk As Michael Smith wrote: > > > Title: "The Design and Implementation of the 4.3 BSD > > UNIX Operating System" > > This book is pretty good. Perhaps it should be remarked again that this book is also called the "Daemon book", since it's cover page bears Kirk McKusick's cute little daemon we all are so proud of. :-) (Except the crappy German edition i'm posessing. :-( ) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Oct 19 02:10:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA15841 for hackers-outgoing; Thu, 19 Oct 1995 02:10:28 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA15836 for ; Thu, 19 Oct 1995 02:10:21 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id CAA13072 for ; Thu, 19 Oct 1995 02:09:55 -0700 Message-Id: <199510190909.CAA13072@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: freebsd-hackers@FreeBSD.ORG Subject: Re: device number for watchdog board driver In-reply-to: Your message of "Thu, 19 Oct 1995 08:32:51 BST." <199510190732.IAA02775@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Oct 1995 02:09:54 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@FreeBSD.ORG Precedence: bulk -------- Curious what are you running over there... dev_mkdb - create /dev database SYNOPSIS dev_mkdb DESCRIPTION The dev_mkdb command creates a db(3) hash access method database in ``/var/run/dev.db'' which contains the names of all of the character and block special files in the ``/dev'' directory, using the file type and the st_rdev field as the key. Keys are a structure containing a mode_t followed by a dev_t, with any padding zero'd out. The former is the type of the file (st_mode & S_IFMT), the latter is the st_rdev field. FILES /dev Device directory. /var/run/dev.db Database file. SEE ALSO ps(1), stat(2), db(3), devname(3), kvm_nlist(3), ttyname(3), kvm_mkdb(8) rah# Regards, Amancio >>> J Wunsch said: > As Amancio Hasty Jr. wrote: > > > > Nope, > > > > I was hoping for something along the lines of sysctl which will tell > > me which devices the system things that it has in the *running kernel* > > > > sysctl -listdevices ?? or a functionally equivalent command. > > Interesting. In order to answer your question, i typed "dev", and > then hit TAB (in tcsh). "dev_mkdb devmenue" was the answer. Ok, "m", > another TAB -- mucho surprised! :-) > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIP E > Never trust an operating system you don't have sources for. ;-) > From owner-freebsd-hackers Thu Oct 19 02:16:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA15995 for hackers-outgoing; Thu, 19 Oct 1995 02:16:21 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA15988 for ; Thu, 19 Oct 1995 02:16:16 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id TAA14955 for hackers@freebsd.org; Thu, 19 Oct 1995 19:20:41 +0930 From: Michael Smith Message-Id: <199510190950.TAA14955@genesis.atrad.adelaide.edu.au> Subject: Re: New userconfig, more patches... To: hackers@freebsd.org Date: Thu, 19 Oct 1995 19:20:41 +0930 (CST) In-Reply-To: <30861556.6709403F@FreeBSD.org> from "Jordan K. Hubbard" at Oct 19, 95 02:07:34 am Content-Type: text Content-Length: 1194 Sender: owner-hackers@freebsd.org Precedence: bulk Jordan K. Hubbard stands accused of saying: > > Jordan K. Hubbard stands accused of saying: > > Ok, how do I go about adding 'port none' and 'port auto' to the syntax for > > config(8)? > > Discuss it in -hackers.. :-) Jordan, of course, is a masochist 8) Nonetheless, I offer a question to the purists : how can this be done? The config.y and lang.l files are more than a mere mortal can stand, at least in my weakened state 8) This is needed for us to be able to handle both devices that have _no_ IO ports, and those that are sure of where to look. Doing it at this level means that if/when some other scheme is implemented, nothing needs to be changed at the kernel-config file level. Also, I could grep for "auto" and find out how to add other keywords. Like, for example "ask" 8) > Jordan -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Thu Oct 19 02:47:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA16777 for hackers-outgoing; Thu, 19 Oct 1995 02:47:26 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA16772 for ; Thu, 19 Oct 1995 02:47:23 -0700 Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id CAA19494 for ; Thu, 19 Oct 1995 02:47:11 -0700 Message-ID: <30861E9E.6D66ED5C@FreeBSD.org> Date: Thu, 19 Oct 1995 02:47:10 -0700 From: "Jordan K. Hubbard" X-Mailer: Mozilla 2.0b1 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: hackers@FreeBSD.org Subject: [Fwd: 100595-SNAP problems: msdosfs, floppy install] Content-Type: multipart/mixed; boundary="---------------------------1736037781884534521386438015" Sender: owner-hackers@FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. -----------------------------1736037781884534521386438015 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bleah... Anyone have any ideas? Nothing has changed with msdosfs between 100595-SNAP and what will be 2.1.. :( -- Jordan -----------------------------1736037781884534521386438015 Content-Type: message/rfc822; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Path: reason.cdrom.com!nntp-ucb.barrnet.net!agate!soda.CSUA.Berkeley.EDU!mconst From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Newsgroups: comp.unix.bsd.freebsd.misc Subject: 100595-SNAP problems: msdosfs, floppy install Date: 19 Oct 1995 07:38:01 GMT Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley Lines: 31 Message-ID: <464v8p$t2d@agate.berkeley.edu> NNTP-Posting-Host: soda.csua.berkeley.edu I'm installing 2.1.0-100595-SNAP, and it's getting errors reading my msdos filesystem. mount_msdosfs() gives a warning that my root directory size is not a multiple of the cluster size; I assume this is because I repartitioned my drive with FIPS and mount_msdosfs() expects a different cluster size based on the partition size. However -- correct me if I'm wrong -- this shouldn't cause errors reading the disk, should it? When I use the emergency holographic shell and run mount_msdos manually, I can access a lot of the files on the disk, but sometimes I will get garbage in directory listings. When I try to install from the msdos partition, gunzip starts complaining about bad input data, and finally sysinstall gives up and returns error. According to Norton Disk Doctor and Scandisk, there are no actual errors on the dos partition. Besides, a directory that looks fine when I look at it once (from the holographic shell) will sometimes look garbled the next, and it won't go back to looking fine until I reboot. The only things I can think of that are even slightly abnormal are the following: first, my dos partition starts at sector 63. Would msdosfs be happier if it was better aligned? Second, when I install the root floppy (either from the image on disk or from the actual floppy) I get a message that trailing garbage was ignored (the message appears right after it installs /stand/ls). All the tools in /stand seem to work, though. Also, I have heard people say that msdosfs is broken; is my problem a symptom of that? If so, is there a workaround? Anyway, I tried installing from floppies as well, and here I got an error that just seems silly: it reads the first disk (bin.aa - bin.af) fine, then it tries to read bin.ag, fails, and aborts the installation. That *shouldn't* happen, should it? :-) -- Michael Constant (mconst@soda.csua.berkeley.edu) -----------------------------1736037781884534521386438015-- From owner-freebsd-hackers Thu Oct 19 03:41:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA17952 for hackers-outgoing; Thu, 19 Oct 1995 03:41:09 -0700 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA17947 ; Thu, 19 Oct 1995 03:40:42 -0700 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA02742; Thu, 19 Oct 1995 11:39:40 +0100 From: Luigi Rizzo Message-Id: <199510191039.LAA02742@labinfo.iet.unipi.it> Subject: Install options To: jkh@FreeBSD.org (Jordan K. Hubbard) Date: Thu, 19 Oct 1995 11:39:39 +0100 (MET) Cc: hackers@FreeBSD.org In-Reply-To: <30861E9E.6D66ED5C@FreeBSD.org> from "Jordan K. Hubbard" at Oct 19, 95 02:46:51 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1080 Sender: owner-hackers@FreeBSD.org Precedence: bulk Have tried the 951005 snap. A few of comments. * I had the whole distribution on a 2.0.5 partition (wd2e), and wanted to install it. It looks like it is not possible to say "mount wd2e, then get the files from ...". It shouldn't be much different from the code that allows you to get the distribution from the cdrom (or the MSDOS partition, as far as I can tell). Would it be possible to add this option in the distribution ? * the shell that is forked on the fourth console is chroot-ed on /mnt, which perhaps prevents from doing damages, but does not allow you to do anything until a FS is actually mounted there. How about keeping it chrooted on / ? Thanks Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== From owner-freebsd-hackers Thu Oct 19 04:58:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA18865 for hackers-outgoing; Thu, 19 Oct 1995 04:58:15 -0700 Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA18851 for ; Thu, 19 Oct 1995 04:58:00 -0700 Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.11/8.6.11) with SMTP id MAA00684 ; Thu, 19 Oct 1995 12:07:47 +0100 To: Joao Carlos Mendes Luis cc: supervisor@alb.asctmd.com, hackers@freebsd.org, jhay@mikom.csir.co.za Subject: Re: IPX feedback request -Reply In-reply-to: Your message of "Wed, 18 Oct 1995 18:32:45 -0200." <199510182032.SAA19360@gaia.coppe.ufrj.br> Date: Thu, 19 Oct 1995 12:07:47 +0100 Message-ID: <682.814100867@palmer.demon.co.uk> From: Gary Palmer Sender: owner-hackers@freebsd.org Precedence: bulk Joao Carlos Mendes Luis stands accused of writing in message ID <199510182032.SAA19360@gaia.coppe.ufrj.br>: >2) Mounting NetWare disks. This is really a problem. How to convert >unix users to netware users ? Should one mount with just one netware >user and show unix users all files as root owned ? The other option >would be to use one IPX socket for EACH unix user, and would require >a much more complex daemon/kernel. Uh-uh. Get the Netware NFS support from Novell. That's how we mount our 4 or 5 Netware drives on all our UN*X boxes at Walnut Creek. It's not perfect, but there's no other way I know to do it :-( >3) Print Services. A netware aware lpd would be useful. Most important: >Should be one which could print from Unix to Netware AND vice-versa. I think that TCP/IP for Netware has lpd support in it. I know I've printed from my UN*X box to a Netware queue, and I believe that there is even support for going the other way (i.e. send jobs from a Netware queue to a UN*X printer). Gary From owner-freebsd-hackers Thu Oct 19 05:07:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA19085 for hackers-outgoing; Thu, 19 Oct 1995 05:07:29 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA19080 for ; Thu, 19 Oct 1995 05:07:27 -0700 Received: from exalt.x.org by expo.x.org id AA00423; Thu, 19 Oct 95 08:06:56 -0400 Received: from localhost by exalt.x.org id IAA01880; Thu, 19 Oct 1995 08:06:54 -0400 Message-Id: <199510191206.IAA01880@exalt.x.org> To: Terry Lambert Cc: hackers@freefall.FreeBSD.org Subject: Re: xterm dumps core In-Reply-To: Your message of Wed, 18 Oct 1995 19:20:55 EST. <199510190220.TAA01615@phaeton.artisoft.com> Organization: X Consortium Date: Thu, 19 Oct 1995 08:06:54 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk >What Andrey *might* be overlooking is when the X server is FreeBSD >and the client is one of the legacy systems. The X server knows nothing about locale. The server and client do not exchange locale information. Locale is entirely client side data. Clients running on legacy systems use the legacy system locale names for things like calls to setlocale. The legacy system locale name is mapped to the corresponding X locale name in order to load the X locale database, which will be used for things like creating input and output contexts. >> As an aside I would say that I believe all these companies take their >> standards compliance very seriously. Yet none of them have a problem with >> not following RFC 7000 in choosing names for their locales. The switch >> from foo.ISO8859-1 to foo.ISO_8859-1 seems completely gratuitous. The fact >> that he will compound it by failing to have any sort of backwards >> compatibility is inexcusable. >The backward compatability won't be an issue for the Pure BSD environemnt; How naive are you? I know at least two people who don't run a "pure FreeBSD" environment. Andrey and I both use X. The only reason I know that Andrey runs X is because he has broken backwards compatibility and now his xterm dumps core. I believe that the average user thinks he or she can just upgrade FreeBSD and continue using the rest of his or her installed software without change. I don't think that's an unreasonable expectation. Backward compatibility will certainly be an issue for those who don't/can't/won't upgrade their XFree86 with the new XFree86-plus-FreeBSD-2.1-changes at the same time they upgrade FreeBSD. It's all well and good to say that people should just automatically do the upgrade, but one need only look at the molassis-like pace at which people are moving from XFree86 3.1.1 to 3.1.2 as evidence that there is considerable resistance to changes like that. >if X throws around only official names internally for things like font >selection, then he should be safe dropping non-RFC 7000 locales entirely. Define safe. By dropping legacy FreeBSD locale names (in preference for RFC 7000 names) without providing a transitional period during which backwards compatiblity is maintained, he is going to either break a lot of people's work environments, or he is going to force them to upgrade XFree86. That doesn't sound like "safe" to me. Given that all it takes is a few symlinks to maintain compatibility I fail to understand his resistance to it. There is no standard that requires locale names take any particular form. Andrey seems to think that it would be convenient to use names that are in use elsewhere, but in reality he's going to inconvenience a lot of people. His argument that backwards compatibility is bad because it allows users to continue using deprecated names is completely specious. He's just being stubborn and FreeBSD customers are going to suffer for his mule headedness. And FWIW, X does only "throw around" official names. Fonts use XLFD names; XLFD is an X Consortium standard. X locale names are registered names in the X Consortium Registry, the were chosen by X Consortium members, i.e. companies like Sony, Fujitsu, NEC, and Okidata, and OMRON, just to name a few. -- Kaleb From owner-freebsd-hackers Thu Oct 19 05:19:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA19203 for hackers-outgoing; Thu, 19 Oct 1995 05:19:38 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA19198 ; Thu, 19 Oct 1995 05:19:31 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA14469; Thu, 19 Oct 1995 22:09:12 +1000 Date: Thu, 19 Oct 1995 22:09:12 +1000 From: Bruce Evans Message-Id: <199510191209.WAA14469@godzilla.zeta.org.au> To: ache@astral.msk.su, terry@lambert.org Subject: Re: Locale stuff: call for conclusion. Cc: bde@zeta.org.au, core@freebsd.org, hackers@freebsd.org, kaleb@x.org, phk@critter.tfs.com, wollman@lcs.mit.edu Sender: owner-hackers@freebsd.org Precedence: bulk >>> > Use ISO 8859-1 as the C locale. >>> >>> We already agree. I expect some sort of patch from you or Kaleb. >>Copy the 8859-1 US locale. No real patch is needed. >Wait. I remember Bruce's proposal to eliminate all upper/lower >tags, he refers to ANSI here and Kaleb agrees. >I have several ideas in this direction: maybe remove punct, space >and alpha tags too? I.e. made it in two parts: control & printable. >Or maybe three parts (control/printable/alpha)? >Bruce, what you can say? The C locale must give the following behaviour for the ctype functions: isalnum: true iff isalpha or isdigit is true (restricted) isalpha: true iff isupper or islower is true (restricted) isctrl: completely implementation defined (unrestricted) isdigit: true iff arg is in [0-9] (restricted) isgraph: true iff arg is "printing" and not a space (unrestricted) islower: true iff arg is in [a-z] (restricted) isprint: true iff arg is "printing" (unrestricted) ispunct: true iff isgraph is true and isalnum is false (unrestricted) isspace: true iff the arg is in [ \f\n\r\t\v] (restricted) isupper: true iff arg is in [A-Z] (restricted) isxdigit: true iff arg is in [0-9a-fA-F] (restricted) Summary: only the upper, lower, alpha and space attributes must be limited. Would this actually help? Anything that deals with words may be confused by national alpha and space characters not satisfying isalpha() and isspace(). Bruce From owner-freebsd-hackers Thu Oct 19 05:44:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA19728 for hackers-outgoing; Thu, 19 Oct 1995 05:44:59 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA19722 for ; Thu, 19 Oct 1995 05:44:56 -0700 Received: from exalt.x.org by expo.x.org id AA00888; Thu, 19 Oct 95 08:44:25 -0400 Received: from localhost by exalt.x.org id IAA01918; Thu, 19 Oct 1995 08:44:23 -0400 Message-Id: <199510191244.IAA01918@exalt.x.org> To: Bruce Evans Cc: hackers@freefall.FreeBSD.org Subject: Re: Locale stuff: call for conclusion. In-Reply-To: Your message of Thu, 19 Oct 1995 22:09:12 EST. <199510191209.WAA14469@godzilla.zeta.org.au> Organization: X Consortium Date: Thu, 19 Oct 1995 08:44:23 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > > The C locale must give the following behaviour for the ctype functions: > > isalnum: true iff isalpha or isdigit is true (restricted) > isalpha: true iff isupper or islower is true (restricted) > isctrl: completely implementation defined (unrestricted) > isdigit: true iff arg is in [0-9] (restricted) > isgraph: true iff arg is "printing" and not a space (unrestricted) > islower: true iff arg is in [a-z] (restricted) > isprint: true iff arg is "printing" (unrestricted) > ispunct: true iff isgraph is true and isalnum is false (unrestricted) > isspace: true iff the arg is in [ \f\n\r\t\v] (restricted) > isupper: true iff arg is in [A-Z] (restricted) > isxdigit: true iff arg is in [0-9a-fA-F] (restricted) > > Summary: only the upper, lower, alpha and space attributes must be limited. > > Would this actually help? Anything that deals with words may be confused > by national alpha and space characters not satisfying isalpha() and > isspace(). > An application that cares will call setlocale() to obtain a locale specific table with the correct information. An application like ls will be able to print more than what it prints now, which is not without drawbacks but I argue that more even with its drawbacks is more useful than nothing at all. -- Kaleb From owner-freebsd-hackers Thu Oct 19 05:55:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA19966 for hackers-outgoing; Thu, 19 Oct 1995 05:55:10 -0700 Received: from jurere (lenzi@mtm.ufsc.br [150.162.1.32]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA19799 for ; Thu, 19 Oct 1995 05:46:26 -0700 Received: (from lenzi@localhost) by jurere (8.6.12/8.6.9) id KAA02747; Thu, 19 Oct 1995 10:45:46 -0200 Date: Thu, 19 Oct 1995 10:45:45 -0200 (EDT) From: lenzi X-Sender: lenzi@jurere To: hackers@freebsd.org Subject: Re: Wow! In-Reply-To: <199510190625.PAA14426@genesis.atrad.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk More tales.... I run TWO systems running 2.0 version in video shops with 1 dumb terminal connected to the com1 port and an internal modem to then com4 port. The systems controls 12000 tapes, using ingres dbms with an "c" written application, that receives updates from a central shop using uucp. There is no UPS, no stabilizer, the system only goes down when the power goes off. I can never imagine if I would ever use another OS for such a task. My friends used Windows, with norton, virus, backups, no-breaks, disk mirrors, backup of fats... When I switch to UNIX and BSD they say I was crazy, the history, showed I was right. Now I am using FreeBSD to make WANS and printer servers, www servers and connecting LANS using OS/2 connect. My customers are giving up from WIN95... I proved them it makes more sense using FreeBSD to manage their WANS than anything else. I don't know why the SCO people does not talk to me any more ??. I am now installing and FreeBSD box in a large SCO reseller to build HTML pages. They became impressioned with the X window and then xfm/fvwm interface available. In a HP reseller, they bought 4 BSD CD-roms for installing at home replacing the windows they have. I'm very satisfied with the system.!!!! Lenzi, Sergio email: lenzi@mtm.ufsc.br From owner-freebsd-hackers Thu Oct 19 06:20:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA20398 for hackers-outgoing; Thu, 19 Oct 1995 06:20:02 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA20387 for ; Thu, 19 Oct 1995 06:19:59 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id IAA27976 for hackers@freebsd.org; Thu, 19 Oct 1995 08:19:28 -0500 From: Joe Greco Message-Id: <199510191319.IAA27976@brasil.moneng.mei.com> Subject: NCR810/Barracuda Question To: hackers@freebsd.org Date: Thu, 19 Oct 1995 08:19:27 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk Hi, Anybody tried the following combination? FreeBSD 2.0.5R, ASUS Pentium MB + NCR 810 (ASUS) controllers, Seagate Barracuda ST15150N 4GB SCSI disk.. (two controllers, each with a 12550 2GB drive and a Micropolis 4GB drive of some sort currently, which are being replaced with the Barracuda 4GB drive because they're flakey). The current setup with the Micropolis works fine. When I hook up the Barras, I get sd3: error reading primary partition table reading fsbn 0 (sd3 bn 0 cn 0 tn 0 s assertion "cp == np->header.cp" failed: file ../../pci/ncr.c line 5235 assertion "cp" failed: file ../../pci/ncr.c line 5236 ncr1: targ 2? ERROR(80:100) (e-ab-2) (8/13)@(10d4:e000000) reg: da 10 0 13 47 8 2 1f 0 e 82 ab 80 0 3 0 Pardon any liberties I inadvertently took, it was rapidly scribbled :-) After Round 1 went like this, I went and laid down a DOS partition table which appeared to work fine and let me format c:, and then tried again, same results. The driver assertion errors worried me however... Anybody able to toss me a suggestion or two? Thanks in advance, ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Thu Oct 19 06:24:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA20557 for hackers-outgoing; Thu, 19 Oct 1995 06:24:05 -0700 Received: from jurere (mtm.ufsc.br [150.162.1.32]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA20498 for ; Thu, 19 Oct 1995 06:22:27 -0700 Received: (from lenzi@localhost) by jurere (8.6.12/8.6.9) id LAA02960; Thu, 19 Oct 1995 11:18:46 -0200 Date: Thu, 19 Oct 1995 11:18:46 -0200 (EDT) From: lenzi X-Sender: lenzi@jurere To: hackers@freebsd.org Subject: dns root name server Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Hi folks, Would someone please help me. I am trying to build a DNS in a net not connected to the internet (20 hosts) ranging from 192.168.16.[1-20] I have already build an DNS in a site connected to the internet. It works fine. But this time the FreeBSD machines and the linux ones are not connected to the internet so, there is no "root name servers to connect". I have tried the sugestion of the DNS and BIND book chapter 14 but it does not work. Any help would be apreciated, like samples of the files db.root, named.boot, zones, revzones... Or where I can find doc about. Thanks, Lenzi, Sergio email: lenzi@mtm.ufsc.br From owner-freebsd-hackers Thu Oct 19 06:49:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA20844 for hackers-outgoing; Thu, 19 Oct 1995 06:49:10 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA20839 for ; Thu, 19 Oct 1995 06:49:05 -0700 Received: by Sysiphos id AA23399 (5.67b/IDA-1.5 for hackers@freebsd.org); Thu, 19 Oct 1995 14:44:24 +0100 Message-Id: <199510191344.AA23399@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Thu, 19 Oct 1995 14:44:24 +0100 In-Reply-To: Joe Greco "NCR810/Barracuda Question" (Oct 19, 8:19) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Joe Greco Subject: Re: NCR810/Barracuda Question Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk On Oct 19, 8:19, Joe Greco wrote: } Subject: NCR810/Barracuda Question } Hi, } } Anybody tried the following combination? } } FreeBSD 2.0.5R, ASUS Pentium MB + NCR 810 (ASUS) controllers, Seagate } Barracuda ST15150N 4GB SCSI disk.. (two controllers, each with a 12550 2GB } drive and a Micropolis 4GB drive of some sort currently, which are being } replaced with the Barracuda 4GB drive because they're flakey). } } The current setup with the Micropolis works fine. } } When I hook up the Barras, I get } } sd3: error reading primary partition table reading fsbn 0 (sd3 bn 0 cn 0 tn } 0 s } assertion "cp == np->header.cp" failed: file ../../pci/ncr.c line 5235 } assertion "cp" failed: file ../../pci/ncr.c line 5236 } ncr1: targ 2? ERROR(80:100) (e-ab-2) (8/13)@(10d4:e000000) ^^^ handshake timeout } reg: da 10 0 13 47 8 2 1f 0 e 82 ab 80 0 3 0 } Pardon any liberties I inadvertently took, it was rapidly scribbled :-) } } After Round 1 went like this, I went and laid down a DOS partition table } which appeared to work fine and let me format c:, and then tried again, same } results. The driver assertion errors worried me however... } } Anybody able to toss me a suggestion or two? Well, my guess is, that there is either some incompatibility between the version of the NCR driver in 2.0.5R and the Barracuda, or your SCSI cable is not up to the job and the Barracuda is more sensitive to that kind of problem ... Are you sure that there are excactly two terminators (i.e. is there possibly one on the Barracuda) ? The driver in the latest SNAP contains improvements that should make it more robust in such situations. You may want to try booting from the latest SNAP boot floppy and see whether that improves the situation. Send mail, if you can't get it to work. Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-hackers Thu Oct 19 08:39:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA23675 for hackers-outgoing; Thu, 19 Oct 1995 08:39:00 -0700 Received: from metal.ops.neosoft.com (root@metal-pluto.ops.NeoSoft.COM [198.65.163.227]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA23670 for ; Thu, 19 Oct 1995 08:38:41 -0700 Received: (from smace@localhost) by metal.ops.neosoft.com (8.6.12/8.6.10) id KAA03934; Thu, 19 Oct 1995 10:27:38 -0500 From: Scott Mace Message-Id: <199510191527.KAA03934@metal.ops.neosoft.com> Subject: Re: NCR810/Barracuda Question To: se@ZPR.Uni-Koeln.DE (Stefan Esser) Date: Thu, 19 Oct 1995 10:27:37 -0500 (CDT) Cc: jgreco@brasil.moneng.mei.com, hackers@freebsd.org In-Reply-To: <199510191344.AA23399@Sysiphos> from "Stefan Esser" at Oct 19, 95 02:44:24 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1280 Sender: owner-hackers@freebsd.org Precedence: bulk > > On Oct 19, 8:19, Joe Greco wrote: > } Subject: NCR810/Barracuda Question > } Hi, > } > } Anybody tried the following combination? > } > } FreeBSD 2.0.5R, ASUS Pentium MB + NCR 810 (ASUS) controllers, Seagate > } Barracuda ST15150N 4GB SCSI disk.. (two controllers, each with a 12550 2GB > } drive and a Micropolis 4GB drive of some sort currently, which are being > } replaced with the Barracuda 4GB drive because they're flakey). > } > } The current setup with the Micropolis works fine. > } > } When I hook up the Barras, I get > } > } sd3: error reading primary partition table reading fsbn 0 (sd3 bn 0 cn 0 tn > } 0 s > } assertion "cp == np->header.cp" failed: file ../../pci/ncr.c line 5235 > } assertion "cp" failed: file ../../pci/ncr.c line 5236 > } ncr1: targ 2? ERROR(80:100) (e-ab-2) (8/13)@(10d4:e000000) > ^^^ > handshake timeout > > } reg: da 10 0 13 47 8 2 1f 0 e 82 ab 80 0 3 0 > > Are you sure that there are excactly two terminators (i.e. is there > possibly one on the Barracuda) ? I've seen similar problems if the terminiation power is coming from the drive and is also coming from the card. I always set it up so the drive gets term power from the bus, and have never had a problem. Scott From owner-freebsd-hackers Thu Oct 19 08:42:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA23802 for hackers-outgoing; Thu, 19 Oct 1995 08:42:54 -0700 Received: from inetgwy.asctmd.com (inetgwy.asctmd.com [198.59.170.33]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA23797 for ; Thu, 19 Oct 1995 08:42:39 -0700 From: supervisor@alb.asctmd.com Received: from alb.asctmd.com (alb.asctmd.com [198.59.170.34]) by inetgwy.asctmd.com (8.6.11/8.6.9) with SMTP id JAA13574 for ; Thu, 19 Oct 1995 09:42:38 -0600 Received: from ALBUQUERQUE-Message_Server by alb.asctmd.com with WordPerfect_Office; Thu, 19 Oct 1995 09:43:38 -0700 Message-Id: X-Mailer: WordPerfect Office 4.0 Date: Thu, 19 Oct 1995 09:40:24 -0700 To: jonny@gaia.coppe.ufrj.br, gary@palmer.demon.co.uk Cc: hackers@freebsd.org, jhay@mikom.csir.co.za Subject: Top 10 List: Why you want IPX supported Sender: owner-hackers@freebsd.org Precedence: bulk 1. Because you want to route. 2. Because you want source to everything you can find. 3. Because Microsoft uses it as a default protocol stack. 4. Because WinSock V2 supports it. 5. Bacause Ray Naroda was cool. 6. Bacause you want to snoop on other types of traffic. 7. Because you hate IP Next Generation. 8. Because Novell should not have all the fun. 9. Because __? 10. Because it is FREE! From owner-freebsd-hackers Thu Oct 19 08:53:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA24151 for hackers-outgoing; Thu, 19 Oct 1995 08:53:13 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA24141 for ; Thu, 19 Oct 1995 08:53:04 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id MAA27586; Thu, 19 Oct 1995 12:07:45 -0400 Date: Thu, 19 Oct 1995 12:07:45 -0400 Message-Id: <199510191607.MAA27586@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Jordan K. Hubbard" From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >Well, this is half me needing to tell *somebody* and half actually >being informative since some of the people on this list have wanted to >test various FreeBSD audio/video apps with me and were frustrated that >I only had that dinkly little V.34 modem. Well no more! > >I have now joined Amancio in the extended peni^H^H^H^Hbandwidth ISDN >club! :-) How much for the whole setup (16550's + Adtran)? I'd like to compare it to a sync card with the less expensive motorolas. You may be able to get 128k with no overhead for a few dollars more. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Thu Oct 19 09:26:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA24949 for hackers-outgoing; Thu, 19 Oct 1995 09:26:56 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA24943 for ; Thu, 19 Oct 1995 09:26:53 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id LAA28235; Thu, 19 Oct 1995 11:25:03 -0500 From: Joe Greco Message-Id: <199510191625.LAA28235@brasil.moneng.mei.com> Subject: Re: Bragging rights.. To: dennis@etinc.com (dennis) Date: Thu, 19 Oct 1995 11:25:02 -0500 (CDT) Cc: jkh@time.cdrom.com, hackers@freebsd.org In-Reply-To: <199510191607.MAA27586@etinc.com> from "dennis" at Oct 19, 95 12:07:45 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > >Well, this is half me needing to tell *somebody* and half actually > >being informative since some of the people on this list have wanted to > >test various FreeBSD audio/video apps with me and were frustrated that > >I only had that dinkly little V.34 modem. Well no more! > > > >I have now joined Amancio in the extended peni^H^H^H^Hbandwidth ISDN > >club! :-) :-) > How much for the whole setup (16550's + Adtran)? I'd like to compare it to a > sync card with the less expensive motorolas. You may be able to get 128k > with no overhead for a few dollars more. 16550's - free essentially because no serious hacker will buy 16450 serial ports. For the 16550-impaired, you can get a *good* card (STB DSP-550) with two 16550's for around $31 wholesale, including a bidir parallel port. The Motorola terminal adapters we use (UTA-220's) can do both sync and async. Never tried the sync. You can find less expensive terminal adapters that only do async. The UTA-220's were around $650 I believe when purchased some time ago. Things like Bitsurfers should be in the <~$400 range. All else being equal, I would agree that the ET/502* solutions are a nice way to go, but there are downsides: 1) The ET/* board is at least $500 more expensive than a comparable 16550 solution. 2) Typically you have to run sync at both ends of the link. Many ISP's will charge you more if you burn one of their valuable sync serial router ports, but could care less about the cheaper async terminal server ports - this can be a difference of up to a few hundred bucks per month! 3) A terminal adaptor that does sync _may_ be more expensive. Of course, the upsides are that there is low host CPU overhead (you're not dealing with 1000 interrupts per second), and you get full 128K (although with the latest Motorola stuff that's apparently a nonissue). Maybe I don't care because either way I dedicate a host to being a router - so host CPU loading is a nonissue to me. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Thu Oct 19 09:48:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA25174 for hackers-outgoing; Thu, 19 Oct 1995 09:48:20 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA25169 for ; Thu, 19 Oct 1995 09:48:17 -0700 Received: from gemini.sdsp.mc.xerox.com ([13.231.132.20]) by alpha.xerox.com with SMTP id <16799(8)>; Thu, 19 Oct 1995 09:47:35 PDT Received: from gnu.mc.xerox.com (gnu.sdsp.mc.xerox.com) by gemini.sdsp.mc.xerox.com (4.1/SMI-4.1) id AA22621; Thu, 19 Oct 95 12:47:33 EDT Received: by gnu.mc.xerox.com (4.1/SMI-4.1) id AA10024; Thu, 19 Oct 95 12:47:32 EDT Message-Id: <9510191647.AA10024@gnu.mc.xerox.com> X-Mailer: exmh version 1.6.4 10/10/95 To: Terry Lambert Cc: chuck@fang.cs.sunyit.edu (Charles Kenneth Green - PRC), hackers@freebsd.org Subject: Re: NetBSD/FreeBSD (pthreads) In-Reply-To: Your message of "Mon, 16 Oct 1995 16:52:02 PDT." <199510162352.QAA25790@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Oct 1995 09:47:31 PDT From: "Marty Leisner" Sender: owner-hackers@freebsd.org Precedence: bulk While I find the MIT pthreads implementation quite clever, what I'm really looking for is pthreads within kernel space... -- marty leisner@sdsp.mc.xerox.com Member of the League for Programming Freedom From owner-freebsd-hackers Thu Oct 19 09:53:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA25272 for hackers-outgoing; Thu, 19 Oct 1995 09:53:28 -0700 Received: from fang.cs.sunyit.edu (fang.cs.sunyit.edu [192.52.220.66]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA25267 for ; Thu, 19 Oct 1995 09:53:26 -0700 Received: (from chuck@localhost) by fang.cs.sunyit.edu (8.6.9/8.6.9) id MAA27395; Thu, 19 Oct 1995 12:52:03 -0400 Date: Thu, 19 Oct 1995 12:52:03 -0400 From: Charles Kenneth Green - PRC Message-Id: <199510191652.MAA27395@fang.cs.sunyit.edu> In-Reply-To: "Marty Leisner" "Re: NetBSD/FreeBSD (pthreads)" (Oct 19, 9:47am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Marty Leisner" Subject: Re: NetBSD/FreeBSD (pthreads) Cc: hackers@freebsd.org, terry@lambert.org Sender: owner-hackers@freebsd.org Precedence: bulk On Oct 19, 9:47am, "Marty Leisner" wrote: } Subject: Re: NetBSD/FreeBSD (pthreads) } } While I find the MIT pthreads implementation quite clever, } what I'm really looking for is pthreads within kernel space... } } } -- } marty } leisner@sdsp.mc.xerox.com } Member of the League for Programming Freedom } } }-- End of excerpt from "Marty Leisner" It's my understanding that there is a gentleman at FreeBSD.ORG who is working on this but there is some issues that have to be resulves. I e-mailed him asking a few questions but I haven't gotten a reply yet. -- Charles Green UN*X System Administration 22 Powell Ave. Apt. B UN*X Security & Whitesboro, NY 13492 Programming From owner-freebsd-hackers Thu Oct 19 10:04:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA25485 for hackers-outgoing; Thu, 19 Oct 1995 10:04:51 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA25478 ; Thu, 19 Oct 1995 10:04:38 -0700 Received: by sequent.kiae.su id AA19324 (5.65.kiae-2 ); Thu, 19 Oct 1995 20:50:10 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 19 Oct 95 20:50:07 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id TAA00469; Thu, 19 Oct 1995 19:37:09 +0300 To: Satoshi Asami Cc: dawes@rf900.physics.usyd.edu.au, hackers@freebsd.org, jmz@freebsd.org, rich@freebsd.org References: <199510190541.WAA02419@silvia.HIP.Berkeley.EDU> In-Reply-To: <199510190541.WAA02419@silvia.HIP.Berkeley.EDU>; from Satoshi Asami at Wed, 18 Oct 1995 22:41:58 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 19 Oct 1995 19:37:08 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: X distribution Lines: 41 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1890 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510190541.WAA02419@silvia.HIP.Berkeley.EDU> Satoshi Asami writes: >Gosh, so many mails on this topic, but I'll reply to this one. > * >If it is distributed as the standard source + patches which get applied > * >at build time, then fine. I'm not really worried about the run-time set. > * > * Yes, it is distributed as standard tarred source and my patch applied > * even at install time. But it is distributed as ready-to-run FreeBSD > * binaries set too with my patch imbedded. >This is not correct. As far as I know, Rich Murphey (who is getting >this mail via CC:), who is responsible for building XFree86 binaries >for the releases, is not using /usr/ports/x11/XFree86. The latter was >invented and maintained by Jean-Marc Zucconi. ??? Oops! Really weird. Why we need two building systems instead of one? BTW, is it correct in part that sources distributed in unmodified way or not? I remember I saw standard XFree gzipped tarballs into 2.0.5 CD. > In particular, if you build from the one in ports, you won't get many > of the programs on the contrib tape (most notably xload and xeyes). It means that contrib tape must be fetched and included to XFree86 ports too. Jean-Marc, what do you say? >I'm not sure what I should do on this, can you (Andrey) check with >Rich and Jean-Marc and make sure we are all in sync? Or you guys >(Rich and Jean-Marc) can just reply to this mail. I think the real way to be in sync is maintain XFree86 port properly and maybe add all missing parts to XFree86 port. Rich, do you got my locale.alias patch or I need to resend? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Thu Oct 19 10:12:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA25672 for hackers-outgoing; Thu, 19 Oct 1995 10:12:39 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA25667 for ; Thu, 19 Oct 1995 10:12:37 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id KAA02008; Thu, 19 Oct 1995 10:11:42 -0700 To: dennis@etinc.com (dennis) cc: hackers@freebsd.org Subject: Re: Bragging rights.. In-reply-to: Your message of "Thu, 19 Oct 1995 12:07:45 EDT." <199510191607.MAA27586@etinc.com> Date: Thu, 19 Oct 1995 10:11:42 -0700 Message-ID: <2005.814122702@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > How much for the whole setup (16550's + Adtran)? I'd like to compare it to a > sync card with the less expensive motorolas. You may be able to get 128k > with no overhead for a few dollars more. The serial cards were dirt.. Maybe $30 apiece, though I think we can almost assume they're free on the motherboard these days.. The TAs were about $650 a pop, I think. I'd need to check the invoice. TAs prices are also going to fall through the floor in the next 6 months, I think. There's just too much demand for them not to. You tell all those new ISDN customers "It's just a faster modem! Hook it to the same serial port!" and they're going to understand what you're saying. The only competing solutions will be all-in-one ISDN cards with nice setup software. Just like external and internal modems compete today.. :) Jordan From owner-freebsd-hackers Thu Oct 19 10:13:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA25713 for hackers-outgoing; Thu, 19 Oct 1995 10:13:34 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA25664 for ; Thu, 19 Oct 1995 10:12:24 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id NAA27921; Thu, 19 Oct 1995 13:25:47 -0400 Date: Thu, 19 Oct 1995 13:25:47 -0400 Message-Id: <199510191725.NAA27921@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Joe Greco From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >16550's - free essentially because no serious hacker will buy 16450 serial >ports. For the 16550-impaired, you can get a *good* card (STB DSP-550) with >two 16550's for around $31 wholesale, including a bidir parallel port. > >The Motorola terminal adapters we use (UTA-220's) can do both sync and >async. Never tried the sync. You can find less expensive terminal adapters >that only do async. The UTA-220's were around $650 I believe when purchased >some time ago. Things like Bitsurfers should be in the <~$400 range. > >All else being equal, I would agree that the ET/502* solutions are a nice >way to go, but there are downsides: > >1) The ET/* board is at least $500 more expensive than a comparable 16550 > solution. >2) Typically you have to run sync at both ends of the link. Many ISP's > will charge you more if you burn one of their valuable sync serial > router ports, but could care less about the cheaper async terminal > server ports - this can be a difference of up to a few hundred bucks > per month! >3) A terminal adaptor that does sync _may_ be more expensive. > Actually the bitsurfers can be gotten for well under $300. and our ET/5025 with RS-232 interface is $400. So you're talking under $700. for a lot more bandwidth and none of the async CPU overhead. Plus if you wanted to go to 56k or frame or frac T1 you'd already have your adapter card. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Thu Oct 19 10:20:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA25835 for hackers-outgoing; Thu, 19 Oct 1995 10:20:17 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA25829 for ; Thu, 19 Oct 1995 10:20:13 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id MAA28328; Thu, 19 Oct 1995 12:19:03 -0500 From: Joe Greco Message-Id: <199510191719.MAA28328@brasil.moneng.mei.com> Subject: Re: Bragging rights.. To: dennis@etinc.com (dennis) Date: Thu, 19 Oct 1995 12:19:02 -0500 (CDT) Cc: hackers@freebsd.org In-Reply-To: <199510191725.NAA27921@etinc.com> from "dennis" at Oct 19, 95 01:25:47 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > Actually the bitsurfers can be gotten for well under $300. and our ET/5025 with > RS-232 interface is $400. So you're talking under $700. for a lot more bandwidth > and none of the async CPU overhead. Plus if you wanted to go to 56k or frame or > frac T1 you'd already have your adapter card. Aside from the avoidance of CPU overhead, what does the ET/5025 buy me? (I don't understand "a lot more bandwidth" - I can definitely do 115200 with a 16550, and since terminal adapters generally cannot do 128000 speeds in async mode, the ET/5025 would be limited to the same speed... certainly no more bandwidth at all....). Now if you can find yourself a TA that can do 230.4 or 460.8, and the ET/5025 is able to do that in async, that might be a benefit. I've retrofitted 16550 ports to run at such speeds and the CPU does eventually reach a point where it has difficulty keeping up on a consistent basis (although this is more likely a driver issue...?) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Thu Oct 19 10:39:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA26076 for hackers-outgoing; Thu, 19 Oct 1995 10:39:29 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA26069 for ; Thu, 19 Oct 1995 10:39:24 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id NAA27991; Thu, 19 Oct 1995 13:52:29 -0400 Date: Thu, 19 Oct 1995 13:52:29 -0400 Message-Id: <199510191752.NAA27991@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Joe Greco From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> Actually the bitsurfers can be gotten for well under $300. and our ET/5025 with >> RS-232 interface is $400. So you're talking under $700. for a lot more bandwidth >> and none of the async CPU overhead. Plus if you wanted to go to 56k or frame or >> frac T1 you'd already have your adapter card. > >Aside from the avoidance of CPU overhead, what does the ET/5025 buy me? > >(I don't understand "a lot more bandwidth" - I can definitely do 115200 with >a 16550, and since terminal adapters generally cannot do 128000 speeds in >async mode, the ET/5025 would be limited to the same speed... certainly no >more bandwidth at all....). > >Now if you can find yourself a TA that can do 230.4 or 460.8, and the >ET/5025 is able to do that in async, that might be a benefit. I've >retrofitted 16550 ports to run at such speeds and the CPU does eventually >reach a point where it has difficulty keeping up on a consistent basis >(although this is more likely a driver issue...?) 115k minus 20% async overhead.....Mostly I've heard about 70k or so for async links....If you don't think that 20-30% is worth an extra hundred dollars, then I guess you're entitled to that. It is, however, a consideration. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Thu Oct 19 10:40:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA26161 for hackers-outgoing; Thu, 19 Oct 1995 10:40:36 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA26153 for ; Thu, 19 Oct 1995 10:40:30 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id NAA27999; Thu, 19 Oct 1995 13:55:12 -0400 Date: Thu, 19 Oct 1995 13:55:12 -0400 Message-Id: <199510191755.NAA27999@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Jordan K. Hubbard" From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> How much for the whole setup (16550's + Adtran)? I'd like to compare it to a >> sync card with the less expensive motorolas. You may be able to get 128k >> with no overhead for a few dollars more. > >The serial cards were dirt.. Maybe $30 apiece, though I think we can >almost assume they're free on the motherboard these days.. The TAs >were about $650 a pop, I think. I'd need to check the invoice. > >TAs prices are also going to fall through the floor in the next 6 >months, I think. There's just too much demand for them not to. You >tell all those new ISDN customers "It's just a faster modem! Hook it >to the same serial port!" and they're going to understand what you're >saying. The only competing solutions will be all-in-one ISDN cards >with nice setup software. Just like external and internal modems >compete today.. :) > So for the same price you could have sync, with a lot more bandwidth. Pretty interesting? You'd be surprised what people really want. Upgradability is a big issue in todays market, and ISDN cards are throwaways when you want to upgrade. Its nice to be able to swap out the external unit and have a higher speed link, or to run a different protocol. Plus with internal cards you have to wait for somebody to write a driver....... Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Thu Oct 19 11:30:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA27198 for hackers-outgoing; Thu, 19 Oct 1995 11:30:44 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA27193 for ; Thu, 19 Oct 1995 11:30:38 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id LAA14459; Thu, 19 Oct 1995 11:29:49 -0700 Message-Id: <199510191829.LAA14459@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: dennis@etinc.com (dennis) cc: "Jordan K. Hubbard" , hackers@freebsd.org Subject: Re: Bragging rights.. In-reply-to: Your message of "Thu, 19 Oct 1995 13:55:12 EDT." <199510191755.NAA27999@etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Oct 1995 11:29:49 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk >>> dennis said: > You'd be surprised what people really want. Upgradability is a big issue > in todays market, and ISDN cards are throwaways when you want to upgrade. > Its nice to be able to swap out the external unit and have a higher speed li nk, > or to run a different protocol. Plus with internal cards you have to wait > for somebody > to write a driver....... There is the small issue of what the telco charges . It costs me about $100/month to keep my 128kb ISDN Line up for the whole month and that includes my ISP v-site.net . So what do the telcos usually charge for a fraction of a T1? Tnks, Amancio From owner-freebsd-hackers Thu Oct 19 11:31:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA27302 for hackers-outgoing; Thu, 19 Oct 1995 11:31:57 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id LAA27297 for ; Thu, 19 Oct 1995 11:31:54 -0700 Received: by sequent.kiae.su id AA15348 (5.65.kiae-2 ); Thu, 19 Oct 1995 22:27:57 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 19 Oct 95 22:27:56 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id VAA00805; Thu, 19 Oct 1995 21:17:59 +0300 To: "Kaleb S. KEITHLEY" , Terry Lambert Cc: hackers@freefall.FreeBSD.org References: <199510191206.IAA01880@exalt.x.org> In-Reply-To: <199510191206.IAA01880@exalt.x.org>; from "Kaleb S. KEITHLEY" at Thu, 19 Oct 1995 08:06:54 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 19 Oct 1995 21:17:59 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: xterm dumps core Lines: 52 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2583 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510191206.IAA01880@exalt.x.org> Kaleb S. KEITHLEY writes: >>The backward compatability won't be an issue for the Pure BSD environemnt; >How naive are you? I know at least two people who don't run a "pure >FreeBSD" environment. Andrey and I both use X. The only reason I know >that Andrey runs X is because he has broken backwards compatibility and >now his xterm dumps core. xterm dumps core due my dumb error copying XLC_LOCALE file manually one time, I already solve this problem with David, so now my xterm works fine in KOI8-R locale even with my hack enabled. >I believe that the average user thinks he or she can just upgrade FreeBSD >and continue using the rest of his or her installed software without >change. I don't think that's an unreasonable expectation. Backward >compatibility will certainly be an issue for those who don't/can't/won't >upgrade their XFree86 with the new XFree86-plus-FreeBSD-2.1-changes at the >same time they upgrade FreeBSD. Your issue must be based on some statistics, i.e. somehow approximately counts users who 1) upgrade to new system and 2) don't upgrade their X. Here my thought on this subject. Old 8859-1 locale names lives very short time (I naively follows X locale naming convention when implement them). So user population using old names is very small. And population who wan't upgrade their X even smaller, moreover, solution for them already exists: "upgrade your X". >And FWIW, X does only "throw around" official names. Fonts use XLFD names; >XLFD is an X Consortium standard. X locale names are registered names in >the X Consortium Registry, the were chosen by X Consortium members, i.e. >companies like Sony, Fujitsu, NEC, and Okidata, and OMRON, just to name >a few. It seems that you not fully understand locale names rules. X Consortium locale names is completely its internal business. System locale name string format must be compliant with XPG3 and using following format. ::= _. ::= based on ISO 639 ::= based on ISO 3166 (country code) ::= based on ISO/RFC1700 They have nothing common with your internal locale names. X must provide translation from valid XPG3 names to their internal names. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Thu Oct 19 11:33:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA27374 for hackers-outgoing; Thu, 19 Oct 1995 11:33:04 -0700 Received: from linux.csie.nctu.edu.tw (jdli@linux.csie.nctu.edu.tw [140.113.235.252]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA27366 for ; Thu, 19 Oct 1995 11:33:01 -0700 Received: (from jdli@localhost) by linux.csie.nctu.edu.tw (8.6.9/8.6.9) id CAA02848 for freebsd-hackers@FreeBSD.ORG; Fri, 20 Oct 1995 02:31:37 +0800 Date: Fri, 20 Oct 1995 02:31:37 +0800 From: Chien-Ta Lee Message-Id: <199510191831.CAA02848@linux.csie.nctu.edu.tw> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Top 10 List: Why you want IPX supported Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > 1. Because you want to route. > 2. Because you want source to everything you can find. > 3. Because Microsoft uses it as a default protocol stack. > 4. Because WinSock V2 supports it. > 5. Bacause Ray Naroda was cool. > 6. Bacause you want to snoop on other types of traffic. > 7. Because you hate IP Next Generation. > 8. Because Novell should not have all the fun. > 9. Because __? Because I/you want to play games (like WarCraft, C&C) via network under FreeBSD's DOGEMU someday .... ;-) > 10. Because it is FREE! -- §õ «Ø ¹F (Adonis) ¥æ¤j¸ê¤u Mail: jdli@csie.nctu.edu.tw From owner-freebsd-hackers Thu Oct 19 11:40:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA27783 for hackers-outgoing; Thu, 19 Oct 1995 11:40:44 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA27777 ; Thu, 19 Oct 1995 11:40:41 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA03023; Thu, 19 Oct 1995 11:33:54 -0700 From: Terry Lambert Message-Id: <199510191833.LAA03023@phaeton.artisoft.com> Subject: Re: Locale stuff: call for conclusion. To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Thu, 19 Oct 1995 11:33:54 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, core@FreeBSD.ORG, hackers@FreeBSD.ORG, kaleb@x.org, phk@critter.tfs.com, wollman@lcs.mit.edu In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 19, 95 05:29:49 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 546 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Well, so lets put XPG3 library into libc and made additional XPG4 > library linked by -lxpg4. I assume that two libraries will > be made from same sources, of course. Do you agree with that? Yes, of course. The problem is in shared library symbol overrride for other libraries. You have to make sure that even though there are identically named symbols, ALL the symbols come from only one or the other. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Oct 19 11:52:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA28325 for hackers-outgoing; Thu, 19 Oct 1995 11:52:29 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA28320 for ; Thu, 19 Oct 1995 11:52:17 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA03088; Thu, 19 Oct 1995 11:45:45 -0700 From: Terry Lambert Message-Id: <199510191845.LAA03088@phaeton.artisoft.com> Subject: Re: Locale stuff: call for conclusion. To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Thu, 19 Oct 1995 11:45:45 -0700 (MST) Cc: bde@zeta.org.au, hackers@freefall.freebsd.org In-Reply-To: <199510191244.IAA01918@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 19, 95 08:44:23 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 741 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > Summary: only the upper, lower, alpha and space attributes must be limited. > > > > Would this actually help? Anything that deals with words may be confused > > by national alpha and space characters not satisfying isalpha() and > > isspace(). > > > > An application that cares will call setlocale() to obtain a locale > specific table with the correct information. An application like > ls will be able to print more than what it prints now, which is not > without drawbacks but I argue that more even with its drawbacks is > more useful than nothing at all. What Kaleb said, word for word. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Oct 19 12:02:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA28570 for hackers-outgoing; Thu, 19 Oct 1995 12:02:05 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA28565 for ; Thu, 19 Oct 1995 12:02:01 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id MAA28344; Thu, 19 Oct 1995 12:28:58 -0500 From: Joe Greco Message-Id: <199510191728.MAA28344@brasil.moneng.mei.com> Subject: Re: Bragging rights.. To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 19 Oct 1995 12:28:58 -0500 (CDT) Cc: multimedia@rah.star-gate.com, hackers@freebsd.org In-Reply-To: <17846.814081219@time.cdrom.com> from "Jordan K. Hubbard" at Oct 18, 95 10:40:19 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > A TA is hooked to a normal FreeBSD box with a standard 16550 serial > port on both ends. I'm using the ADTRAN TAs - not the dirt-cheapest > or the highest tech, but they're the only ones that did *everything* I > wanted and did it *now*. Talk to Motorola and it's "yeah, you can > have async bonding in a PROM upgrade RSN - we promise!" We've been running the Motorola async bonding since July or August. Fire your rep. > and a pair of FreeBSD boxes - no other custom hardware of any sort was > required. I can see a lot of 386 boxes coming back to service as > dedicated ISDN routers in the next few years.. :-) I've been using 386's for a long time as a "dedicated application" platform... they make great routers, terminal servers, etc. etc. Maybe this works better for me because I believe in functional separation, and generally don't have a box doing lots of diverse chores. It definitely makes individual system upgrades much easier to contemplate. However it tends to add to the number of systems that must be upgraded :-/ > Now if I can just get my hands on a pair of ISDN cards to get that > full pipe.. [he gazes off into the distance..] This is a good thing to be looking towards. ... JG From owner-freebsd-hackers Thu Oct 19 12:03:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA28653 for hackers-outgoing; Thu, 19 Oct 1995 12:03:38 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA28648 for ; Thu, 19 Oct 1995 12:03:36 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA03125; Thu, 19 Oct 1995 11:57:22 -0700 From: Terry Lambert Message-Id: <199510191857.LAA03125@phaeton.artisoft.com> Subject: Re: xterm dumps core To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Thu, 19 Oct 1995 11:57:22 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.freebsd.org In-Reply-To: <199510191206.IAA01880@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 19, 95 08:06:54 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2903 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >The backward compatability won't be an issue for the Pure BSD environemnt; > > How naive are you? I know at least two people who don't run a "pure > FreeBSD" environment. Andrey and I both use X. The only reason I know > that Andrey runs X is because he has broken backwards compatibility and > now his xterm dumps core. As long as the locale data on the machine matches the environment variables on the machine (something you have to have now anyway, even to get a bogus name to work), then it will work. > I believe that the average user thinks he or she can just upgrade FreeBSD > and continue using the rest of his or her installed software without > change. I don't think that's an unreasonable expectation. Backward > compatibility will certainly be an issue for those who don't/can't/won't > upgrade their XFree86 with the new XFree86-plus-FreeBSD-2.1-changes at the > same time they upgrade FreeBSD. Certainly, they must upgrade their alias database, but that's true of the proprietary naming on some vendors systems anyway. > It's all well and good to say that people should just automatically do > the upgrade, but one need only look at the molassis-like pace at which > people are moving from XFree86 3.1.1 to 3.1.2 as evidence that there is > considerable resistance to changes like that. Well, you did too good a job with 3.1.1, and you don't fix what isn't broken. 8-). > >if X throws around only official names internally for things like font > >selection, then he should be safe dropping non-RFC 7000 locales entirely. > > Define safe. By dropping legacy FreeBSD locale names (in preference for > RFC 7000 names) without providing a transitional period during which > backwards compatiblity is maintained, he is going to either break a lot > of people's work environments, or he is going to force them to upgrade > XFree86. Safe, as in "having a reasonable expectation of continued function". This would be a bigger problem, I guess, if in place upgrades worked very, very reliably. Eventually it will be a problem, but that's all the more reason to address the issue *now*. The only environments I see breaking are those with applications with hard coded strings in them. An in-place upgrade, as long as it hit the environment variables, the data files, and the X aliases file, should function without error. > And FWIW, X does only "throw around" official names. Fonts use XLFD names; > XLFD is an X Consortium standard. X locale names are registered names in > the X Consortium Registry, the were chosen by X Consortium members, i.e. > companies like Sony, Fujitsu, NEC, and Okidata, and OMRON, just to name > a few. Fine; then there's no external represenation problems that can't be fixed via the aliases file. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Oct 19 12:13:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA28906 for hackers-outgoing; Thu, 19 Oct 1995 12:13:09 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA28901 for ; Thu, 19 Oct 1995 12:13:05 -0700 Received: by sequent.kiae.su id AA23481 (5.65.kiae-2 ); Thu, 19 Oct 1995 23:00:51 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 19 Oct 95 23:00:50 +0300 Received: from ache.dialup.demos.ru (ache.dialup.demos.ru [194.87.17.241]) by ache.dialup.demos.ru (8.6.11/8.6.9) with SMTP id VAA01019; Thu, 19 Oct 1995 21:51:55 +0300 Message-Id: <199510191851.VAA01019@ache.dialup.demos.ru> Date: Thu, 19 Oct 95 18:51:56 0000 From: "Andrey A. Chernov, Black Mage" Organization: Ha-olahm Yetzirah X-Mailer: Mozilla 1.12 (X11; I; FreeBSD 2.2-CURRENT i386) Mime-Version: 1.0 To: terry@lambert.org, hackers@freebsd.org Subject: FYI, good WWW page which allows visually compare ISO 8859-* X-Url: http://www.cs.tu-berlin.de/~czyborra/charsets/ Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-hackers@freebsd.org Precedence: bulk http://www.cs.tu-berlin.de/~czyborra/charsets/ -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Thu Oct 19 12:18:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA29116 for hackers-outgoing; Thu, 19 Oct 1995 12:18:53 -0700 Received: from eros.library.csusb.edu (eros.library.csusb.edu [139.182.195.200]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA29103 for ; Thu, 19 Oct 1995 12:18:41 -0700 Received: (from nwestfal@localhost) by eros.library.csusb.edu (8.6.11/8.6.9) id MAA05961; Thu, 19 Oct 1995 12:03:11 -0700 Date: Thu, 19 Oct 1995 12:03:10 -0700 (PDT) From: "Neal E. Westfall" To: lenzi cc: hackers@freebsd.org Subject: Re: dns root name server In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk What I did was just change the named.root file to have a singe root server pointing at 127.0.0.1, and it worked fine. Just delete all the rest of them. On Thu, 19 Oct 1995, lenzi wrote: > Hi folks, > > Would someone please help me. > > I am trying to build a DNS in a net not connected > to the internet (20 hosts) ranging from 192.168.16.[1-20] > > I have already build an DNS in a site connected to the > internet. It works fine. But this time the FreeBSD machines > and the linux ones are not connected to the internet so, > there is no "root name servers to connect". > > I have tried the sugestion of the DNS and BIND book chapter 14 but > it does not work. > > Any help would be apreciated, like samples of the > files db.root, named.boot, zones, revzones... Or where > I can find doc about. > > Thanks, > > > > Lenzi, Sergio > email: lenzi@mtm.ufsc.br > > > From owner-freebsd-hackers Thu Oct 19 12:20:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA29197 for hackers-outgoing; Thu, 19 Oct 1995 12:20:22 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA29174 for ; Thu, 19 Oct 1995 12:20:07 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA28484; Thu, 19 Oct 1995 14:18:55 -0500 From: Joe Greco Message-Id: <199510191918.OAA28484@brasil.moneng.mei.com> Subject: Re: Bragging rights.. To: dennis@etinc.com (dennis) Date: Thu, 19 Oct 1995 14:18:54 -0500 (CDT) Cc: hackers@freebsd.org In-Reply-To: <199510191752.NAA27991@etinc.com> from "dennis" at Oct 19, 95 01:52:29 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > >Now if you can find yourself a TA that can do 230.4 or 460.8, and the > >ET/5025 is able to do that in async, that might be a benefit. I've > >retrofitted 16550 ports to run at such speeds and the CPU does eventually > >reach a point where it has difficulty keeping up on a consistent basis > >(although this is more likely a driver issue...?) > > 115k minus 20% async overhead.....Mostly I've heard about 70k or so for > async links....If you don't think that 20-30% is worth an extra hundred > dollars, then I guess you're entitled to that. It is, however, a consideration. Really??!! I had a 386DX/40 that routinely chatted with a 386DX/16 at 115200 (UUCP over TCP/IP as a SLIP connection) and consistently hit > 10.5K/sec -- the number ran around 11K/sec during non-peak times here at MEI, and I attribute the difference to our network rather than any of the FreeBSD boxes involved (our network traffic peaks at wire saturation at times, and never falls below 10%). The 386/40 was also running the uucico for one side... These two systems had jacked-up serial ports. When I ran them at 230.4K, I started to hit serial overruns, but with TCP/IP retries they still were capable of hitting 19K/sec (which amazes me!!!) However at 19K/sec the 386DX/16 was definitely swamped, and the 386DX/40 was having troubles too (it was also maintaining the uucico, several uncompress/gzip's concurrently, another uucico running over ANOTHER SLIP link over a V.FC modem connection to sol.net). For those who are wondering what the hell I was doing :-) I was receiving a full news feed. Because I could not directly connect to the local network (firewall restrictions), I came in through a carefully gated, hardwired SLIP connection into the terminal server, and ran UUCP to gather batches of news. That was the high speed link :-) I then turned around and tossed it into sol.net's WAN structure with an ordinary POTS/V.FC modem. In the process, because the news was only compressed, I uncompressed it and used gzip -9 on it to achieve more virtual throughput :-) So I don't see an extra 20-30%, and I do see MORE than an "extra hundred dollars" (you have a product that sells for $139 with two ports?? I didn't think so). Everyone else please note: I am a satisfied ET customer, but I am just having a hard time swallowing this line of reasoning :-) ... JG From owner-freebsd-hackers Thu Oct 19 12:30:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA29534 for hackers-outgoing; Thu, 19 Oct 1995 12:30:15 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA29505 ; Thu, 19 Oct 1995 12:30:06 -0700 Received: by sequent.kiae.su id AA27429 (5.65.kiae-2 ); Thu, 19 Oct 1995 23:18:28 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 19 Oct 95 23:18:26 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id WAA01082; Thu, 19 Oct 1995 22:03:24 +0300 To: Terry Lambert Cc: bde@zeta.org.au, core@FreeBSD.ORG, hackers@FreeBSD.ORG, kaleb@x.org, phk@critter.tfs.com, wollman@lcs.mit.edu References: <199510191833.LAA03023@phaeton.artisoft.com> In-Reply-To: <199510191833.LAA03023@phaeton.artisoft.com>; from Terry Lambert at Thu, 19 Oct 1995 11:33:54 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 19 Oct 1995 22:03:24 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: Locale stuff: call for conclusion. Lines: 22 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 957 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message <199510191833.LAA03023@phaeton.artisoft.com> Terry Lambert writes: >> Well, so lets put XPG3 library into libc and made additional XPG4 >> library linked by -lxpg4. I assume that two libraries will >> be made from same sources, of course. Do you agree with that? >Yes, of course. >The problem is in shared library symbol overrride for other libraries. >You have to make sure that even though there are identically named >symbols, ALL the symbols come from only one or the other. Well, it is linker issue and can be solved (if not already solved) after separation will be done. What happens if I link -lxpg4 statically and left libc as dynamic? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Thu Oct 19 12:50:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA29801 for hackers-outgoing; Thu, 19 Oct 1995 12:50:03 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA29789 for ; Thu, 19 Oct 1995 12:49:56 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id QAA28405; Thu, 19 Oct 1995 16:03:35 -0400 Date: Thu, 19 Oct 1995 16:03:35 -0400 Message-Id: <199510192003.QAA28405@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Joe Greco From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> >Now if you can find yourself a TA that can do 230.4 or 460.8, and the >> >ET/5025 is able to do that in async, that might be a benefit. I've >> >retrofitted 16550 ports to run at such speeds and the CPU does eventually >> >reach a point where it has difficulty keeping up on a consistent basis >> >(although this is more likely a driver issue...?) >> >> 115k minus 20% async overhead.....Mostly I've heard about 70k or so for >> async links....If you don't think that 20-30% is worth an extra hundred >> dollars, then I guess you're entitled to that. It is, however, a consideration. > >Really??!! > >I had a 386DX/40 that routinely chatted with a 386DX/16 at 115200 (UUCP over >TCP/IP as a SLIP connection) and consistently hit > 10.5K/sec -- the number >ran around 11K/sec during non-peak times here at MEI, and I attribute the >difference to our network rather than any of the FreeBSD boxes involved (our >network traffic peaks at wire saturation at times, and never falls below >10%). 90K still isn't 128k though??!!!!! So what does this have to do with ISDN, anyway? You realize, of course, that you're going through a Telephone switch digitally with ISDN..... >The 386/40 was also running the uucico for one side... > >These two systems had jacked-up serial ports. When I ran them at 230.4K, I >started to hit serial overruns, but with TCP/IP retries they still were >capable of hitting 19K/sec (which amazes me!!!) However at 19K/sec the >386DX/16 was definitely swamped, and the 386DX/40 was having troubles too >(it was also maintaining the uucico, several uncompress/gzip's concurrently, >another uucico running over ANOTHER SLIP link over a V.FC modem connection >to sol.net). And with a sync card your 386-16 wouldn't have overloaded...... >For those who are wondering what the hell I was doing :-) I was receiving >a full news feed. Because I could not directly connect to the local network >(firewall restrictions), I came in through a carefully gated, hardwired SLIP >connection into the terminal server, and ran UUCP to gather batches of news. >That was the high speed link :-) I then turned around and tossed it into >sol.net's WAN structure with an ordinary POTS/V.FC modem. In the process, >because the news was only compressed, I uncompressed it and used gzip -9 on >it to achieve more virtual throughput :-) Yes....I think that this is a typical scenario...what does this have to do with anything?????? .of course, we could do on-the-fly compression (without all of the fancy crap) and do better as well. db ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Thu Oct 19 13:13:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA00357 for hackers-outgoing; Thu, 19 Oct 1995 13:13:53 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA00352 for ; Thu, 19 Oct 1995 13:13:47 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id NAA28685; Thu, 19 Oct 1995 13:13:44 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id NAA29801; Thu, 19 Oct 1995 13:07:26 -0700 Message-Id: <199510192007.NAA29801@corbin.Root.COM> To: dennis@etinc.com (dennis) cc: Joe Greco , hackers@freebsd.org Subject: Re: Bragging rights.. In-reply-to: Your message of "Thu, 19 Oct 95 16:03:35 EDT." <199510192003.QAA28405@etinc.com> From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 19 Oct 1995 13:07:20 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >>> 115k minus 20% async overhead.....Mostly I've heard about 70k or so for >>> async links....If you don't think that 20-30% is worth an extra hundred >>> dollars, then I guess you're entitled to that. It is, however, a >consideration. >> >>Really??!! >> > >>I had a 386DX/40 that routinely chatted with a 386DX/16 at 115200 (UUCP over >>TCP/IP as a SLIP connection) and consistently hit > 10.5K/sec -- the number >>ran around 11K/sec during non-peak times here at MEI, and I attribute the >>difference to our network rather than any of the FreeBSD boxes involved (our >>network traffic peaks at wire saturation at times, and never falls below >>10%). > >90K still isn't 128k though??!!!!! So what does this have to do with ISDN, >anyway? You realize, of course, that you're going through a Telephone switch >digitally with ISDN..... Let me add a bit of sanity to this part of the discussion. 115200 baud async will give you about 11.52Kbytes/second if you have no packet overhead. 115200 baud sync will give you 14.40Kbytes/second if you have no packet overhead. Why? Because we're talking bits - async is 8 data bits plus 1 start and 1 stop bit...10 bits. With synchronous serial, it's just 8 data bits. So sync always has the potential to give you 25% more bytes throughput at the same bit rate compared to async. Now with sync you'll also be running at a faster bit rate (128000bits/sec). This is 16Kbytes/second. This is 38.9% faster. -DG From owner-freebsd-hackers Thu Oct 19 13:16:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA00431 for hackers-outgoing; Thu, 19 Oct 1995 13:16:02 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA00426 for ; Thu, 19 Oct 1995 13:15:57 -0700 Received: by sequent.kiae.su id AA09637 (5.65.kiae-2 ); Fri, 20 Oct 1995 00:06:52 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Fri, 20 Oct 95 00:06:51 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id XAA02724; Thu, 19 Oct 1995 23:06:00 +0300 To: "Kaleb S. KEITHLEY" Cc: hackers@freefall.FreeBSD.org References: <199510191930.PAA02590@exalt.x.org> In-Reply-To: <199510191930.PAA02590@exalt.x.org>; from "Kaleb S. KEITHLEY" at Thu, 19 Oct 1995 15:30:23 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 19 Oct 1995 23:06:00 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: xterm dumps core Lines: 31 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1448 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510191930.PAA02590@exalt.x.org> Kaleb S. KEITHLEY writes: >If you choose to do so, and gratuitously break backwards compatibility >with prior releases of FreeBSD as a result, that is inexcusable. If >your own experience with xterm didn't teach you something about how >important backwards compatibility is, then I will have no sympathy for >you when 2.1 is released and people have problems. What you count as "prior releases" is ONLY ONE INTERIM RELEASE: 2.0.5! 8859-1 locale isn't supported in 2.0 yet. 2.0.5 not treated as full release, it is only short term solution, so please stop talking about "prior releases" and of incredible amount of their users who wants backward compatibility. >> X must provide translation from valid XPG3 names to their >> internal names. >The X Consortium Sample Implementation provides translations for names >that are used in released versions of operating systems. There is no >requirement to do any more than that. As I indicated previously, when >2.1 is real, I will consider adding your new names to the locale.alias >file in the X Consortium Sample Implementation. Well, sounds good. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Thu Oct 19 13:29:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA00692 for hackers-outgoing; Thu, 19 Oct 1995 13:29:23 -0700 Received: from moon.pr.erau.edu (root@moon.pr.erau.edu [192.101.135.8]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA00672 ; Thu, 19 Oct 1995 13:29:10 -0700 Received: from web by moon.pr.erau.edu with smtp (Smail3.1.29.1 #16) id m0t61aC-0002HCC; Thu, 19 Oct 95 13:28 MST Date: Thu, 19 Oct 1995 13:28:56 -0700 (MST) From: Stephen Waits X-Sender: swaits@web To: questions@freebsd.org, hackers@freebsd.org Subject: SendPage or TPage ported? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Has anyone gotten either Sendpage or TPage or any other alphanumeric paging software ported? TIA, Steve From owner-freebsd-hackers Thu Oct 19 13:45:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA01144 for hackers-outgoing; Thu, 19 Oct 1995 13:45:13 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA01136 for ; Thu, 19 Oct 1995 13:45:08 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA03267; Thu, 19 Oct 1995 13:36:52 -0700 From: Terry Lambert Message-Id: <199510192036.NAA03267@phaeton.artisoft.com> Subject: Re: NetBSD/FreeBSD (pthreads) To: leisner@sdsp.mc.xerox.com (Marty Leisner) Date: Thu, 19 Oct 1995 13:36:52 -0700 (MST) Cc: terry@lambert.org, chuck@fang.cs.sunyit.edu, hackers@freebsd.org In-Reply-To: <9510191647.AA10024@gnu.mc.xerox.com> from "Marty Leisner" at Oct 19, 95 09:47:31 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 489 Sender: owner-hackers@freebsd.org Precedence: bulk > While I find the MIT pthreads implementation quite clever, > what I'm really looking for is pthreads within kernel space... To clarify matters: Apparently, there is now a HotJava port in alpha on Solaris/Linux/NetBSD that uses user space threads (pthreads). No, I don't know the release schedule. I still favor a kernel implementation as well. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Oct 19 13:59:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA01496 for hackers-outgoing; Thu, 19 Oct 1995 13:59:41 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA01488 ; Thu, 19 Oct 1995 13:59:30 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA03306; Thu, 19 Oct 1995 13:52:48 -0700 From: Terry Lambert Message-Id: <199510192052.NAA03306@phaeton.artisoft.com> Subject: Re: Locale stuff: call for conclusion. To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Thu, 19 Oct 1995 13:52:48 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, core@FreeBSD.ORG, hackers@FreeBSD.ORG, kaleb@x.org, phk@critter.tfs.com, wollman@lcs.mit.edu In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 19, 95 10:03:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 606 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > >The problem is in shared library symbol overrride for other libraries. > >You have to make sure that even though there are identically named > >symbols, ALL the symbols come from only one or the other. > > Well, it is linker issue and can be solved (if not already solved) > after separation will be done. What happens if I link -lxpg4 > statically and left libc as dynamic? I haven't checked lately. My impression is that it would fail to operate as expected. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Oct 19 14:01:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA01731 for hackers-outgoing; Thu, 19 Oct 1995 14:01:53 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA01715 for ; Thu, 19 Oct 1995 14:01:39 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id VAA04890 ; Thu, 19 Oct 1995 21:58:17 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id VAA09605 ; Thu, 19 Oct 1995 21:58:16 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id VAA13053; Thu, 19 Oct 1995 21:50:36 +0100 (MET) From: Ollivier Robert Message-Id: <199510192050.VAA13053@keltia.freenix.fr> Subject: Re: FreeBSD Kernel Development... To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 19 Oct 1995 21:50:36 +0100 (MET) Cc: freebsd-hackers@freebsd.org, crosswjo@hp-pcd.cv.hp.com In-Reply-To: <199510190834.JAA03004@uriah.heep.sax.de> from "J Wunsch" at Oct 19, 95 09:34:23 am X-Operating-System: FreeBSD 2.2-CURRENT ctm#1224 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk It seems that J Wunsch said: > Perhaps it should be remarked again that this book is also called the > "Daemon book", since it's cover page bears Kirk McKusick's cute little > daemon we all are so proud of. :-) (Except the crappy German edition When is the 4.4 version due ? -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #0: Sat Oct 14 19:05:10 MET 1995 From owner-freebsd-hackers Thu Oct 19 14:08:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA02028 for hackers-outgoing; Thu, 19 Oct 1995 14:08:55 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA02019 ; Thu, 19 Oct 1995 14:08:50 -0700 Received: by sequent.kiae.su id AA29698 (5.65.kiae-2 ); Fri, 20 Oct 1995 00:55:13 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Fri, 20 Oct 95 00:55:12 +0300 Received: from ache.dialup.demos.ru (ache.dialup.demos.ru [194.87.17.241]) by ache.dialup.demos.ru (8.6.11/8.6.9) with SMTP id XAA02786; Thu, 19 Oct 1995 23:30:55 +0300 Message-Id: <199510192030.XAA02786@ache.dialup.demos.ru> Date: Thu, 19 Oct 95 20:30:57 0000 From: "Andrey A. Chernov, Black Mage" Organization: Ha-olahm Yetzirah X-Mailer: Mozilla 1.12 (X11; I; FreeBSD 2.2-CURRENT i386) Mime-Version: 1.0 To: terry@lambert.org, wollman@freebsd.org, hackers@freebsd.org Subject: XPG3 - XPG4 Base Migration Guide X-Url: http://www.xopen.co.uk/public/pubs/catalog/g204.htm Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Sender: owner-hackers@freebsd.org Precedence: bulk Interesting reference quoted below... Can anybody please somehow find this doc, look at it and tell, how it can be useful for FreeBSD localization? > XPG3 - XPG4 Base Migration Guide > > Description: > > This document provides detailed guidance on how to migrate applications from > Issue 3 to Issue 4 of the System Interfaces and Headers and Commands and > Utilities that make up the Base Profile of XPG3 and XPG4. It also covers > C-language migration. It is intended for application developers, experienced in > C-language programming or familiar with the shell command language and > utilities. It is also intended for interactive users of the shell interpreter. > The document provides useful information for implementors. The reader will need > access to XPG3 (Document Set T921) and XPG4 (Document Set T906). > > Document Reference: > > X/Open Guide G204 ISBN 1-872630-49-9 28cm. 272p. pbk. 755g. 7/92 > > List Price/Shipping Code: > > $ 85.00 £ 52.00 B > > Format/History: > > Subject Category: > > OPERATING SYSTEM SERVICES > ------------------------------------------------------------------------------- > > Wherever possible we have identified contact points for further information. If > you can't find the information you need, please contact X/Open at any of its > offices. > > ------------------------------------------------------------------------------- > Copyright X/Open Company Limited, © 1995 -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Thu Oct 19 15:01:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA03479 for hackers-outgoing; Thu, 19 Oct 1995 15:01:12 -0700 Received: from fieber-john.campusview.indiana.edu (Fieber-John.campusview.indiana.edu [149.159.1.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA03471 for ; Thu, 19 Oct 1995 15:01:01 -0700 Received: (from jfieber@localhost) by fieber-john.campusview.indiana.edu (8.6.11/8.6.9) id QAA15802; Thu, 19 Oct 1995 16:52:47 -0500 Date: Thu, 19 Oct 1995 16:52:46 -0500 (EST) From: John Fieber To: Gary Palmer cc: Joao Carlos Mendes Luis , supervisor@alb.asctmd.com, hackers@freebsd.org, jhay@mikom.csir.co.za Subject: Re: IPX feedback request -Reply In-Reply-To: <682.814100867@palmer.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Thu, 19 Oct 1995, Gary Palmer wrote: > >3) Print Services. A netware aware lpd would be useful. Most important: > >Should be one which could print from Unix to Netware AND vice-versa. > > I think that TCP/IP for Netware has lpd support in it. I know I've > printed from my UN*X box to a Netware queue, and I believe that there > is even support for going the other way (i.e. send jobs from a Netware > queue to a UN*X printer). Yes, Netware servers *can* support lpd. Whether a particular server *does* is a political issue. For me, the result of that particular political issue is a half hour walk (15 minutes each direction) in whatever the weather in southern Indiana to pickup a printout, as opposed to a 5 minute walk downstairs. Yes, I would be quite pleased be able to talk directly to a netware server that doesn't speak lpd. -john == jfieber@indiana.edu =========================================== == http://fieber-john.campusview.indiana.edu/~jfieber ============ From owner-freebsd-hackers Thu Oct 19 15:27:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA04405 for hackers-outgoing; Thu, 19 Oct 1995 15:27:33 -0700 Received: from werple.net.au (0@werple.mira.net.au [203.9.190.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA04394 for ; Thu, 19 Oct 1995 15:27:19 -0700 Received: from cimaxp1.UUCP (Ucimlogi@localhost) by werple.net.au (8.7/8.7) with UUCP id IAA02052 for hackers@freebsd.org; Fri, 20 Oct 1995 08:22:46 +1000 (EST) Message-Id: <199510192222.IAA02052@werple.net.au> X-Authentication-Warning: werple.net.au: Ucimlogi set sender to cimaxp1!jb using -f Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA31215; Fri, 20 Oct 1995 08:25:28 +1000 From: John Birrell Subject: Re: NetBSD/FreeBSD (pthreads) To: mira!sdsp.mc.xerox.com!leisner@werple.net.au (Marty Leisner) Date: Fri, 20 Oct 1995 08:25:25 +1000 (EST) Cc: hackers@freebsd.org, jb@cimlogic.com.au In-Reply-To: <9510191647.AA10024@gnu.mc.xerox.com> from "Marty Leisner" at Oct 19, 95 09:47:31 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk Marty, > > > While I find the MIT pthreads implementation quite clever, > what I'm really looking for is pthreads within kernel space... About 4 weeks ago I downloaded the MIT pthreads (from sipb.mit.edu:/pub/pthreads). I was looking for POSIX thread functionality that would let us use code that currently works under OSF/1, VxWorks and LynxOS. Until I had a _good_ look at user-space threads, I thought that kernel space threads were the *only* way to go. I've since changed my mind and I think that user-space threads are worthwhile for us. So much so, we're basing a product on them. I'm curious about why you *need* kernel threads. If it's fast context switching you need, then a SIGVTALRM followed by either a longjmp or a sigreturn is pretty quick. If you end up trying to use the MIT threads, watch out! We ended up completely retructuring the code to a more sane (IMHO) implementation. > > > -- > marty > leisner@sdsp.mc.xerox.com > Member of the League for Programming Freedom > > > -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 9600 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137 From owner-freebsd-hackers Thu Oct 19 15:43:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA04734 for hackers-outgoing; Thu, 19 Oct 1995 15:43:51 -0700 Received: from gaia.coppe.ufrj.br (root@gaia.coppe.ufrj.br [146.164.63.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA04716 for ; Thu, 19 Oct 1995 15:41:39 -0700 Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.6.11/8.6.9) id UAA27904; Thu, 19 Oct 1995 20:37:04 -0200 From: Joao Carlos Mendes Luis Message-Id: <199510192237.UAA27904@gaia.coppe.ufrj.br> Subject: Re: IPX feedback request -Reply To: gary@palmer.demon.co.uk (Gary Palmer) Date: Thu, 19 Oct 1995 20:37:03 -0200 (EDT) Cc: hackers@freebsd.org In-Reply-To: <682.814100867@palmer.demon.co.uk> from "Gary Palmer" at Oct 19, 95 12:07:47 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1433 Sender: owner-hackers@freebsd.org Precedence: bulk > Joao Carlos Mendes Luis stands accused of writing in message ID > <199510182032.SAA19360@gaia.coppe.ufrj.br>: > >2) Mounting NetWare disks. This is really a problem. How to convert > >unix users to netware users ? Should one mount with just one netware > >user and show unix users all files as root owned ? The other option > >would be to use one IPX socket for EACH unix user, and would require > >a much more complex daemon/kernel. > > Uh-uh. Get the Netware NFS support from Novell. That's how we mount > our 4 or 5 Netware drives on all our UN*X boxes at Walnut Creek. > It's not perfect, but there's no other way I know to do it :-( > > >3) Print Services. A netware aware lpd would be useful. Most important: > >Should be one which could print from Unix to Netware AND vice-versa. > > I think that TCP/IP for Netware has lpd support in it. I know I've > printed from my UN*X box to a Netware queue, and I believe that there > is even support for going the other way (i.e. send jobs from a Netware > queue to a UN*X printer). I know both of them, but they're not free. :) Sounds like "If you need an IP Router, buy Solaris". No, I prefer FreeBSD. Dot. It's free, It's good, I have the sources ! Anyway, I was just wondering... Jonny -- Joao Carlos Mendes Luis jonny@coe.ufrj.br +55 21 290-4698 ( Job ) jonny@adc.coppe.ufrj.br Network Manager UFRJ/COPPE/CISI Universidade Federal do Rio de Janeiro From owner-freebsd-hackers Thu Oct 19 15:46:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA04836 for hackers-outgoing; Thu, 19 Oct 1995 15:46:50 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA04829 for ; Thu, 19 Oct 1995 15:46:47 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id PAA23918; Thu, 19 Oct 1995 15:46:20 -0700 From: Julian Elischer Message-Id: <199510192246.PAA23918@ref.tfs.com> Subject: Re: NetBSD/FreeBSD (pthreads) To: cimaxp1!jb@werple.net.au (John Birrell) Date: Thu, 19 Oct 1995 15:46:19 -0700 (PDT) Cc: mira!sdsp.mc.xerox.com!leisner@werple.net.au, hackers@freebsd.org, jb@cimlogic.com.au In-Reply-To: <199510192222.IAA02052@werple.net.au> from "John Birrell" at Oct 20, 95 08:25:25 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 379 Sender: owner-hackers@freebsd.org Precedence: bulk > I'm curious about why you *need* kernel threads. usually it's for several blocking IO streams.. > > If you end up trying to use the MIT threads, watch out! We ended up completely > retructuring the code to a more sane (IMHO) implementation. this is the stuff you ended up using right? have you forwarded your changes back? are you doing this under FreeBSD as well? julian From owner-freebsd-hackers Thu Oct 19 16:03:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA05081 for hackers-outgoing; Thu, 19 Oct 1995 16:03:56 -0700 Received: from gateway.cybernet.com ([192.245.33.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA05075 for ; Thu, 19 Oct 1995 16:03:52 -0700 Received: from root@spiffy.cybernet.com by gateway.cybernet.com (8.6.8/1.0A) id TAA22861; Thu, 19 Oct 1995 19:53:59 -0400 Date: Thu, 19 Oct 1995 19:53:59 -0400 Content-Length: 1291 Message-ID: X-Mailer: XFMail 0.3-beta [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199510192007.NAA29801@corbin.Root.COM> Reply-To: root@spiffy.cybernet.com Organization: Cybernet Systems Corporation From: "Mark J. Taylor" To: Subject: Re: Bragging rights.. Sender: owner-hackers@freebsd.org Precedence: bulk On 10/19/95 20:25:56 David Greenman wrote: [clip] > > Let me add a bit of sanity to this part of the discussion. 115200 baud async >will give you about 11.52Kbytes/second if you have no packet overhead. 115200 >baud sync will give you 14.40Kbytes/second if you have no packet overhead. > Why? Because we're talking bits - async is 8 data bits plus 1 start and 1 >stop bit...10 bits. With synchronous serial, it's just 8 data bits. So sync >always has the potential to give you 25% more bytes throughput at the same bit >rate compared to async. > Now with sync you'll also be running at a faster bit rate (128000bits/sec). >This is 16Kbytes/second. This is 38.9% faster. > >-DG As a slightly interested party, I'd like to ask: As mentioned recently on -hackers, isn't it possilbe to up the rate of the serial chip simply by doubling (or quadding) the rate of the xtal driving the chip? Many (most?) 16550 chips should be able to handle a Fmax higher than they are being driven, and with 16 byte FIFOS (set to trigger at 14 bytes), the interrupt overhead would not necessarily be increased. Is the same xtal trick applicable to sync serial, to get 32 KBytes/second @256000 bits/sec (as opposed to 28.8 KBytes/sec async serial @230400 bits/sec)? -Mark Taylor mtaylor@cybernet.com From owner-freebsd-hackers Thu Oct 19 16:27:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA05403 for hackers-outgoing; Thu, 19 Oct 1995 16:27:33 -0700 Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA05395 ; Thu, 19 Oct 1995 16:27:29 -0700 Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA12071; Fri, 20 Oct 95 00:27:53 +0100 Date: Fri, 20 Oct 95 00:27:53 +0100 Message-Id: <9510192327.AA12071@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: ache@astral.msk.su Cc: asami@cs.berkeley.edu, dawes@rf900.physics.usyd.edu.au, hackers@freebsd.org, rich@freebsd.org In-Reply-To: Subject: Re: X distribution X-Mailer: Emacs Sender: owner-hackers@freebsd.org Precedence: bulk >>>>> aka Andrey A Chernov, Black Mage writes: > In message <199510190541.WAA02419@silvia.HIP.Berkeley.EDU> Satoshi > Asami writes: >> Gosh, so many mails on this topic, but I'll reply to this one. >> * >If it is distributed as the standard source + patches which get applied >> * >at build time, then fine. I'm not really worried about the run-time set. >> * >> * Yes, it is distributed as standard tarred source and my patch applied >> * even at install time. But it is distributed as ready-to-run FreeBSD >> * binaries set too with my patch imbedded. >> This is not correct. As far as I know, Rich Murphey (who is getting >> this mail via CC:), who is responsible for building XFree86 binaries >> for the releases, is not using /usr/ports/x11/XFree86. The latter was >> invented and maintained by Jean-Marc Zucconi. > ??? Oops! Really weird. Why we need two building systems instead of one? > BTW, is it correct in part that sources distributed in unmodified > way or not? I remember I saw standard XFree gzipped tarballs into > 2.0.5 CD. There are not two building systems. XFree86 provide binaries and READMEs telling how to rebuild the system from sources and patches. The XFree 'port' is a translation of this in a makefile >> In particular, if you build from the one in ports, you won't get many >> of the programs on the contrib tape (most notably xload and xeyes). > It means that contrib tape must be fetched and included to > XFree86 ports too. Jean-Marc, what do you say? Not all programs of the contrib tape are part of the XFree86 distribution, only a subset. I did not include them on the XFree port because 1) I am lazy 2) most of them are useless (IMO) >> I'm not sure what I should do on this, can you (Andrey) check with >> Rich and Jean-Marc and make sure we are all in sync? Or you guys >> (Rich and Jean-Marc) can just reply to this mail. > I think the real way to be in sync is maintain XFree86 port > properly and maybe add all missing parts to XFree86 port. > Rich, do you got my locale.alias patch or I need to resend? > -- > Andrey A. Chernov : And I rest so composedly, /Now, in my bed, > ache@astral.msk.su : That any beholder /Might fancy me dead - > http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. > RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-hackers Thu Oct 19 16:37:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA05657 for hackers-outgoing; Thu, 19 Oct 1995 16:37:33 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA05646 for ; Thu, 19 Oct 1995 16:37:27 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id QAA29023; Thu, 19 Oct 1995 16:37:19 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id QAA00227; Thu, 19 Oct 1995 16:37:02 -0700 Message-Id: <199510192337.QAA00227@corbin.Root.COM> To: root@spiffy.cybernet.com cc: hackers@freebsd.org Subject: Re: Bragging rights.. In-reply-to: Your message of "Thu, 19 Oct 95 19:53:59 EDT." From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 19 Oct 1995 16:37:01 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk > >On 10/19/95 20:25:56 David Greenman wrote: >[clip] >> >> Let me add a bit of sanity to this part of the discussion. 115200 baud async > >>will give you about 11.52Kbytes/second if you have no packet overhead. 115200 >>baud sync will give you 14.40Kbytes/second if you have no packet overhead. >> Why? Because we're talking bits - async is 8 data bits plus 1 start and 1 >>stop bit...10 bits. With synchronous serial, it's just 8 data bits. So sync >>always has the potential to give you 25% more bytes throughput at the same bit >>rate compared to async. >> Now with sync you'll also be running at a faster bit rate (128000bits/sec). >>This is 16Kbytes/second. This is 38.9% faster. >> >>-DG > > >As a slightly interested party, I'd like to ask: > >As mentioned recently on -hackers, isn't it possilbe to up the rate of the serial >chip simply by doubling (or quadding) the rate of the xtal driving the chip? >Many (most?) 16550 chips should be able to handle a Fmax higher than they are being >driven, and with 16 byte FIFOS (set to trigger at 14 bytes), the interrupt overhead >would not necessarily be increased. > >Is the same xtal trick applicable to sync serial, to get 32 KBytes/second @256000 >bits/sec (as opposed to 28.8 KBytes/sec async serial @230400 bits/sec)? Apparantly, *some* 16550 UARTs will do this, but as far as I know, this would be overclocking most versions out there and might result in the part overheating (or simply not working at 230K baud). -DG From owner-freebsd-hackers Thu Oct 19 16:37:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA05670 for hackers-outgoing; Thu, 19 Oct 1995 16:37:35 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA05653 for ; Thu, 19 Oct 1995 16:37:31 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA11663; Fri, 20 Oct 1995 00:37:27 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id AAA28514; Fri, 20 Oct 1995 00:37:27 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id XAA04832; Thu, 19 Oct 1995 23:30:27 +0100 From: J Wunsch Message-Id: <199510192230.XAA04832@uriah.heep.sax.de> Subject: Re: device number for watchdog board driver To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Thu, 19 Oct 1995 23:30:26 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510190909.CAA13072@rah.star-gate.com> from "Amancio Hasty Jr." at Oct 19, 95 02:09:54 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 669 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk As Amancio Hasty Jr. wrote: > > Curious what are you running over there... > > dev_mkdb - create /dev database > > SYNOPSIS > dev_mkdb > > Interesting. In order to answer your question, i typed "dev", and > > then hit TAB (in tcsh). "dev_mkdb devmenue" was the answer. Ok, "m", > > another TAB -- mucho surprised! :-) I know how to read a man page. Seriously. :-) But i wrote that the next char was "m", not "_". This gave me "devm", which tcsh has been expanding to "devmenue"... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Oct 19 16:37:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA05707 for hackers-outgoing; Thu, 19 Oct 1995 16:37:42 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA05682 for ; Thu, 19 Oct 1995 16:37:36 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA11671; Fri, 20 Oct 1995 00:37:32 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id AAA28520; Fri, 20 Oct 1995 00:37:32 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id XAA05141; Thu, 19 Oct 1995 23:51:01 +0100 From: J Wunsch Message-Id: <199510192251.XAA05141@uriah.heep.sax.de> Subject: Re: New userconfig, more patches... To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Thu, 19 Oct 1995 23:51:01 +0100 (MET) Cc: hackers@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510190950.TAA14955@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 19, 95 07:20:41 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1725 Sender: owner-hackers@freebsd.org Precedence: bulk As Michael Smith wrote: > > Jordan, of course, is a masochist 8) Nonetheless, I offer a question to the > purists : how can this be done? The config.y and lang.l files are more > than a mere mortal can stand, at least in my weakened state 8) Without any warranties, blah, blah, blah: Index: config/config.y =================================================================== RCS file: /home/cvs/src/usr.sbin/config/config.y,v retrieving revision 1.11 diff -u -r1.11 config.y --- 1.11 1995/07/18 06:11:34 +++ config.y 1995/10/19 22:49:19 @@ -9,6 +9,7 @@ %token ANY %token ARGS %token AT +%token AUTO %token BIO %token BUS %token COMMA @@ -37,6 +38,7 @@ %token MINUS %token NET %token NEXUS +%token NONE %token ON %token OPTIONS %token MAKEOPTIONS @@ -607,6 +609,10 @@ = { cur.d_port = ns($2); } | PORT NUMBER = { cur.d_portn = $2; } | + PORT AUTO + = { cur.d_portn = -1; } | + PORT NONE + = { cur.d_portn = -2; } | TTY = { cur.d_mask = "tty"; } | BIO Index: config/lang.l =================================================================== RCS file: /home/cvs/src/usr.sbin/config/lang.l,v retrieving revision 1.7 diff -u -r1.7 lang.l --- 1.7 1995/07/17 23:38:15 +++ lang.l 1995/10/19 22:45:48 @@ -52,6 +52,7 @@ { "and", AND }, { "args", ARGS }, { "at", AT }, + { "auto", AUTO }, #if MACHINE_I386 { "bio", BIO }, { "bus", BUS }, @@ -86,6 +87,7 @@ { "net", NET }, #endif MACHINE_I386 { "nexus", NEXUS }, + { "none", NONE }, { "on", ON }, { "options", OPTIONS }, #if MACHINE_I386 -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Oct 19 16:38:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA05786 for hackers-outgoing; Thu, 19 Oct 1995 16:38:46 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA05777 ; Thu, 19 Oct 1995 16:38:39 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA11667; Fri, 20 Oct 1995 00:37:30 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id AAA28517; Fri, 20 Oct 1995 00:37:30 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id XAA05069; Thu, 19 Oct 1995 23:43:10 +0100 From: J Wunsch Message-Id: <199510192243.XAA05069@uriah.heep.sax.de> Subject: Re: [Fwd: 100595-SNAP problems: msdosfs, floppy install] To: jkh@FreeBSD.org (Jordan K. Hubbard) Date: Thu, 19 Oct 1995 23:43:09 +0100 (MET) Cc: hackers@FreeBSD.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <30861E9E.6D66ED5C@FreeBSD.org> from "Jordan K. Hubbard" at Oct 19, 95 02:47:10 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 546 Sender: owner-hackers@FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > Bleah... Anyone have any ideas? Nothing has changed with msdosfs > between 100595-SNAP and what will be 2.1.. :( In other words: nothing has been fixed. :-] > The only things I can think of that are even slightly abnormal are the > following: first, my dos partition starts at sector 63. This evily sounds like there would be a "disk manager"... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Oct 19 16:43:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA06026 for hackers-outgoing; Thu, 19 Oct 1995 16:43:40 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA06021 for ; Thu, 19 Oct 1995 16:43:37 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA03590; Thu, 19 Oct 1995 16:34:05 -0700 From: Terry Lambert Message-Id: <199510192334.QAA03590@phaeton.artisoft.com> Subject: Re: NetBSD/FreeBSD (pthreads) To: julian@ref.tfs.com (Julian Elischer) Date: Thu, 19 Oct 1995 16:34:05 -0700 (MST) Cc: cimaxp1!jb@werple.net.au, leisner@sdsp.mc.xerox.com, hackers@FreeBSD.ORG, jb@cimlogic.com.au In-Reply-To: <199510192246.PAA23918@ref.tfs.com> from "Julian Elischer" at Oct 19, 95 03:46:19 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1042 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > I'm curious about why you *need* kernel threads. > > usually it's for several blocking IO streams.. It also buys you competition for a single threaded process as if it were multiple processes. For a threaded process that use to be multiple processes (ie: NFS daemons, etc.), this allows "fairer" competition for process quantum than would otherwise be the case. Identical function with no gratuitous blocking (I/O isn't necessarily the only blocking operation: wait(), etc.) when there is at least one thread capable of running requires n==m for an n:m mapping of user to kernel threads. It's a neat problem to think about. I have a process (but not a formula) for determining throuput/efficiency based on ratios of n:m. This problem is almost exactly analogous to loop-unrolling parallelization of a process for SMP and/or treading of predicate-inependent I/O across multiple I/O channels. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Oct 19 16:57:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA06456 for hackers-outgoing; Thu, 19 Oct 1995 16:57:27 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA06451 for ; Thu, 19 Oct 1995 16:57:25 -0700 Received: from gemini.sdsp.mc.xerox.com ([13.231.132.20]) by alpha.xerox.com with SMTP id <17420(5)>; Thu, 19 Oct 1995 16:09:09 PDT Received: from willow.mc.xerox.com (willow.sdsp.mc.xerox.com) by gemini.sdsp.mc.xerox.com (4.1/SMI-4.1) id AA27222; Thu, 19 Oct 95 19:00:23 EDT Received: by willow.mc.xerox.com (4.1/SMI-4.1) id AA03362; Thu, 19 Oct 95 19:00:48 EDT Message-Id: <9510192300.AA03362@willow.mc.xerox.com> To: Julian Elischer Cc: cimaxp1!jb@werple.net.au (John Birrell), mira!sdsp.mc.xerox.com!leisner@werple.net.au, hackers@freebsd.org, jb@cimlogic.com.au Subject: Re: NetBSD/FreeBSD (pthreads) In-Reply-To: Your message of "Thu, 19 Oct 1995 15:46:19 PDT." <199510192246.PAA23918@ref.tfs.com> Date: Thu, 19 Oct 1995 15:58:57 PDT From: "Marty Leisner" Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510192246.PAA23918@ref.tfs.com>, you write: >> I'm curious about why you *need* kernel threads. > >usually it's for several blocking IO streams.. > pthreads handles this... But it does this via (I think...) all I/O being nonblocking, and if it would block it then run another thread.... I haven't looked at the code for a while, but kernel threads would be much more efficient (if a task blocks on I/O, it blocks inside the kernel, rather then muxing on select...) I agree you can implement user-space pthreads efficiently if multiple processor are compute bound...but this is not why you have threads... Also, each kernel call will need context switches, which slow things down... marty From owner-freebsd-hackers Thu Oct 19 16:58:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA06556 for hackers-outgoing; Thu, 19 Oct 1995 16:58:53 -0700 Received: from aries.ai.net (ai.net [198.69.35.206]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA06444 for ; Thu, 19 Oct 1995 16:56:27 -0700 Received: (from nc@localhost) by aries.ai.net (8.6.11/8.6.12) id TAA00867; Thu, 19 Oct 1995 19:54:53 -0400 Date: Thu, 19 Oct 1995 19:54:53 -0400 (EDT) From: Network Coordinator To: "Amancio Hasty Jr." cc: dennis , "Jordan K. Hubbard" , hackers@freebsd.org Subject: Re: Bragging rights.. In-Reply-To: <199510191829.LAA14459@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk > So what do the telcos usually charge for a fraction of a T1? > The price of a full-T1 usually. -Jerry. From owner-freebsd-hackers Thu Oct 19 17:04:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA06657 for hackers-outgoing; Thu, 19 Oct 1995 17:04:53 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA06652 for ; Thu, 19 Oct 1995 17:04:50 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id TAA28849; Thu, 19 Oct 1995 19:03:19 -0500 From: Joe Greco Message-Id: <199510200003.TAA28849@brasil.moneng.mei.com> Subject: Re: Bragging rights.. To: root@spiffy.cybernet.com Date: Thu, 19 Oct 1995 19:03:19 -0500 (CDT) Cc: hackers@freebsd.org In-Reply-To: from "Mark J. Taylor" at Oct 19, 95 07:53:59 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > On 10/19/95 20:25:56 David Greenman wrote: > [clip] > > > > Let me add a bit of sanity to this part of the discussion. 115200 baud async > > >will give you about 11.52Kbytes/second if you have no packet overhead. 115200 > >baud sync will give you 14.40Kbytes/second if you have no packet overhead. > > Why? Because we're talking bits - async is 8 data bits plus 1 start and 1 > >stop bit...10 bits. With synchronous serial, it's just 8 data bits. So sync > >always has the potential to give you 25% more bytes throughput at the same bit > >rate compared to async. > > Now with sync you'll also be running at a faster bit rate (128000bits/sec). > >This is 16Kbytes/second. This is 38.9% faster. > > > >-DG Granted; but you need sync hardware on both ends of the connection, then. My original point is that that is typically more expensive... > As a slightly interested party, I'd like to ask: > > As mentioned recently on -hackers, isn't it possilbe to up the rate of the serial > chip simply by doubling (or quadding) the rate of the xtal driving the chip? Generally. Check the chip specs. NS parts can be. 3.6864 MHz = 2x (so "57600" stty value yields a 115200 real bit rate) 7.3728 MHz = 4x (max supported by many chips) > Many (most?) 16550 chips should be able to handle a Fmax higher than they are being > driven, and with 16 byte FIFOS (set to trigger at 14 bytes), the interrupt overhead > would not necessarily be increased. No, because you're receiving (or sending) at a higher rate of speed. The per-call interrupt overhead may not be higher, but there will be twice (or four times) as many interrupts as you would normally expect. > Is the same xtal trick applicable to sync serial, to get 32 KBytes/second @256000 > bits/sec (as opposed to 28.8 KBytes/sec async serial @230400 bits/sec)? Dennis started this thread on the assertion that his sync serial cards can do very high speeds quite easily :-) I have a 386DX/40 routing between a T1 (1.544Mb/s) and an Ethernet and it handles average mixes of traffic without any trouble (it runs into problems if you start saturating the T1 with small packets however). It is QUITE impressive :-) I don't think you'd need to do any crystal switches to do what you describe, since the board is designed to be quite flexible. However, you are probably limited to packet modes such as PPP (Dennis? I am extrapolating here, any solid info? I was never able to access raw data streams, although I only looked briefly) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Thu Oct 19 17:16:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA07041 for hackers-outgoing; Thu, 19 Oct 1995 17:16:34 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA07034 ; Thu, 19 Oct 1995 17:16:28 -0700 Received: by sequent.kiae.su id AA05827 (5.65.kiae-2 ); Fri, 20 Oct 1995 04:04:37 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Fri, 20 Oct 95 04:04:37 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id DAA04753; Fri, 20 Oct 1995 03:02:43 +0300 To: Jean-Marc Zucconi Cc: asami@cs.berkeley.edu, dawes@rf900.physics.usyd.edu.au, hackers@freebsd.org, rich@freebsd.org References: <9510192327.AA12071@cabri.obs-besancon.fr> In-Reply-To: <9510192327.AA12071@cabri.obs-besancon.fr>; from Jean-Marc Zucconi at Fri, 20 Oct 95 00:27:53 +0100 Message-Id: Organization: Olahm Ha-Yetzirah Date: Fri, 20 Oct 1995 03:02:43 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: X distribution Lines: 21 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1009 Sender: owner-hackers@freebsd.org Precedence: bulk In message <9510192327.AA12071@cabri.obs-besancon.fr> Jean-Marc Zucconi writes: >There are not two building systems. XFree86 provide binaries and >READMEs telling how to rebuild the system from sources and >patches. The XFree 'port' is a translation of this in a makefile I not mean building ideas/algorithms here, but real life situation. Now I fix XFree port (assume that Satoshi will commit the fix in near future because it emergency needed) and not shure that this fix will be passed to another building system (I mean Rich here). If Rich will builds the system from your port (and maybe some needed programs from contrib additionly), this problem can't even occurse. Rich, please, consider my proposal. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Thu Oct 19 17:39:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA07508 for hackers-outgoing; Thu, 19 Oct 1995 17:39:10 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA07498 for ; Thu, 19 Oct 1995 17:39:05 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id UAA29399; Thu, 19 Oct 1995 20:52:48 -0400 Date: Thu, 19 Oct 1995 20:52:48 -0400 Message-Id: <199510200052.UAA29399@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Joe Greco From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk Joe Greco says..... >Dennis started this thread on the assertion that his sync serial cards can >do very high speeds quite easily :-) Actually, Dennis started this thread by trying to get a price reference for the Async solution that Jordan referred to....I did not start it by saying that sync is better than async. My point was that if for about the same money you can have a more flexible solution that will use less of your CPU it is worth considering. Unlike most of you, my perspective is marketability....not necessarily your (wrong) opinion that async is just as good. If its not cheaper, which has always been the sole selling point for async, then it's a no-brainer. I have a 386DX/40 routing between a >T1 (1.544Mb/s) and an Ethernet and it handles average mixes of traffic >without any trouble (it runs into problems if you start saturating the T1 >with small packets however). It is QUITE impressive :-) I don't think >you'd need to do any crystal switches to do what you describe, since the >board is designed to be quite flexible. However, you are probably limited to >packet modes such as PPP (Dennis? I am extrapolating here, any solid >info? I was never able to access raw data streams, although I only looked >briefly) Its limited to whatever I wrote for it so far. There's not much market for raw data streams. We can run 2 dos boxes back to back at 4mbs and run all day. The overruns you're seeing with small packets is a FreeBSD/CPU power issue in processing IP packets, and can be linearly corrected by increasing CPU power...the capabilities are limited only by what unix can handle as the per packet latency is fairly high, particularly on a slow box. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Thu Oct 19 17:42:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA07645 for hackers-outgoing; Thu, 19 Oct 1995 17:42:36 -0700 Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA07635 for ; Thu, 19 Oct 1995 17:42:33 -0700 Received: (from mbarkah@localhost) by hemi.com (8.6.11/8.6.9) id SAA15031; Thu, 19 Oct 1995 18:46:30 -0600 From: Ade Barkah Message-Id: <199510200046.SAA15031@hemi.com> Subject: Re: FreeBSD Kernel Development... To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 19 Oct 1995 18:46:29 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, crosswjo@hp-pcd.cv.hp.com In-Reply-To: <199510190834.JAA03004@uriah.heep.sax.de> from "J Wunsch" at Oct 19, 95 09:34:23 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 788 Sender: owner-hackers@freebsd.org Precedence: bulk > As Michael Smith wrote: > > > > > Title: "The Design and Implementation of the 4.3 BSD > > > UNIX Operating System" > > > > This book is pretty good. > > Perhaps it should be remarked again that this book is also called the > "Daemon book", since it's cover page bears Kirk McKusick's cute little > daemon we all are so proud of. :-) ... Yeah, it is ESPECIALLY great beside this really cool t-shirt with the daemon I just bought from McKusick yesterday (paid him the $15 in a bar, no less.) The caption on the shirt reads, "May the source be with you". =) =) =) -Ade -------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - www: -------------------------------------------------------------------- From owner-freebsd-hackers Thu Oct 19 17:49:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA07863 for hackers-outgoing; Thu, 19 Oct 1995 17:49:14 -0700 Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA07855 for ; Thu, 19 Oct 1995 17:49:09 -0700 Received: (from mbarkah@localhost) by hemi.com (8.6.11/8.6.9) id SAA15098; Thu, 19 Oct 1995 18:52:47 -0600 From: Ade Barkah Message-Id: <199510200052.SAA15098@hemi.com> Subject: Re: Bragging rights.. To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Thu, 19 Oct 1995 18:52:47 -0600 (MDT) Cc: dennis@etinc.com, jkh@time.cdrom.com, hackers@freebsd.org In-Reply-To: <199510191829.LAA14459@rah.star-gate.com> from "Amancio Hasty Jr." at Oct 19, 95 11:29:49 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 787 Sender: owner-hackers@freebsd.org Precedence: bulk > There is the small issue of what the telco charges . It costs me about > $100/month to keep my 128kb ISDN Line up for the whole month and that > includes my ISP v-site.net . > > So what do the telcos usually charge for a fraction of a T1? In the order of $500 depending how far away you are from your isp's POP, plus another $1200 to $1600 to pay the provider (we're talking 128kbps fractional t1.) Some telcos charge you for a full t1 even if you only use a fraction of it. To bad I can't get ISDN at home for my FreeBSD machine =( =(. (complain complain U.S. West) -Ade -------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - www: -------------------------------------------------------------------- From owner-freebsd-hackers Thu Oct 19 17:52:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA08018 for hackers-outgoing; Thu, 19 Oct 1995 17:52:55 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA08013 ; Thu, 19 Oct 1995 17:52:53 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA03727; Thu, 19 Oct 1995 17:46:39 -0700 From: Terry Lambert Message-Id: <199510200046.RAA03727@phaeton.artisoft.com> Subject: Re: [Fwd: 100595-SNAP problems: msdosfs, floppy install] To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 19 Oct 1995 17:46:39 -0700 (MST) Cc: jkh@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199510192243.XAA05069@uriah.heep.sax.de> from "J Wunsch" at Oct 19, 95 11:43:09 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 506 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > The only things I can think of that are even slightly abnormal are the > > following: first, my dos partition starts at sector 63. > > This evily sounds like there would be a "disk manager"... That would be "partition table at sector 64". An odd start boundry is annoying, but not fatal (I guess it could be if the FS really, really screws up page-based I/O). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Oct 19 18:22:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA08570 for hackers-outgoing; Thu, 19 Oct 1995 18:22:27 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA08565 for ; Thu, 19 Oct 1995 18:22:25 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA03776; Thu, 19 Oct 1995 18:12:35 -0700 From: Terry Lambert Message-Id: <199510200112.SAA03776@phaeton.artisoft.com> Subject: Re: NetBSD/FreeBSD (pthreads) To: leisner@sdsp.mc.xerox.com (Marty Leisner) Date: Thu, 19 Oct 1995 18:12:35 -0700 (MST) Cc: julian@ref.tfs.com, cimaxp1!jb@werple.net.au, leisner@sdsp.mc.xerox.com, hackers@FreeBSD.ORG, jb@cimlogic.com.au In-Reply-To: <9510192300.AA03362@willow.mc.xerox.com> from "Marty Leisner" at Oct 19, 95 03:58:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4668 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > In message <199510192246.PAA23918@ref.tfs.com>, you write: > >> I'm curious about why you *need* kernel threads. > > > >usually it's for several blocking IO streams.. > > pthreads handles this... No it doesn't. > But it does this via (I think...) all I/O being nonblocking, and if > it would block it then run another thread.... This is how it runs, period: It changes blocking operations into non-blocking operations plus a context switch. If you get a real blocking operation (ie: one outside the model, etc.), then all threads are blocked because the context switcher can't run unless it converts the call. Like fstatfs/statfs on a remote but down server (yit's not a select()'able operation). > I haven't looked at the code for a while, but kernel threads would be > much more efficient (if a task blocks on I/O, it blocks inside > the kernel, rather then muxing on select...) It would be more efficient for actual blocking I/O. The way to hack this easily is an exec loader and alternate call gate, with rewritten trap code. If one thread entered on another threads blocked resource (ie: two I/O's pending on the same fd), then you'd be screwed. > I agree you can implement user-space pthreads efficiently if > multiple processor are compute bound...but this is not > why you have threads... Right. > Also, each kernel call will need context switches, which slow things > down... The context switch will occur, period. It makes little real difference given the current context switch overhead whether it happens in the kernel or in user space (except if it's in the kernel, you get more time quanta to play with, which is good if it's your process and bad if it's someone else's process. 8-)). There are certain things we can do in delaying full context switching, like lazy switching of FPU state, etc., but that'd benefit regular context switching as well. The main thing that's avoided is the page table swap and ptde invalidation, which can be avoided in common using async I/O to do your threading. The ideal for a threaded app is: 1) Never blocked waiting for processor resource while quanta remains (requires kernel threads and a 1:1 correspondance between kernel and user space threads in case all user space threads make blocking calls). 2) Never voluntarily context switch (requires the use of async operations for all blocking operations, and a loose binding between kernel/user threads -- in other words, the thread scheduler will have to live in user space and have kernel space controls). The user space threads buy you the ability to completely consume your process quantum, as long as you convert blocking calls into non-blocking calls plus a context switch. The kernel space threads buy you the ability to compete for quanta with other processes as if you were actually multiple processes, as well as buying you the ability to not context switch all user space threads when a blocking operation forces a voluntary context switch of one kernel thread. Page table entry and FPU state caching are not entirely effective with multiple kernel threads, unless you manage both association in the scheduling queue (to ensure one kernel thread follows the other to cause a PTE "cache hit") and (in the SMP case), you ensure processor preference binding (since a PTE entry and FPU state are bound to the processor). There is very little difference, other than page table entry management, between "the ideal situation" and multiple processes with the ability to share heap and open descriptor tables. This doesn't translate to "ideal" for other processes on the system, since average time between when they get the processor will be increased by each threaded "process" taking asclose to its full quanta as the mapping from synchronous to asynchronus calls + context switch will allow. NetWare for UNIX actually uses the multiple process/shared context model (the SVR4 model does not have the ability to context switch in user space on async I/O with kernel thread management). For a machine dedicated to providing a small set of specific services, the kernel threading model is actually inferior to the user space threading (async I/O) model. The shared context/kernel thread model, on the other hand, scales well to SMP, whereas the user space threading will not benefit from multiple processors. SMP scaling is, of course, dependent on better than low grain parallelism ...it requires kernel multiple entrancy to be effectively utilized for scaling parallelizable tasks. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Oct 19 18:30:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA08856 for hackers-outgoing; Thu, 19 Oct 1995 18:30:22 -0700 Received: from werple.net.au (0@werple.mira.net.au [203.9.190.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA08781 for ; Thu, 19 Oct 1995 18:28:03 -0700 Received: from cimaxp1.UUCP (Ucimlogi@localhost) by werple.net.au (8.7/8.7) with UUCP id LAA09401 for hackers@freebsd.org; Fri, 20 Oct 1995 11:14:12 +1000 (EST) Message-Id: <199510200114.LAA09401@werple.net.au> X-Authentication-Warning: werple.net.au: Ucimlogi set sender to cimaxp1!jb using -f Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA17483; Fri, 20 Oct 1995 11:16:56 +1000 From: John Birrell Subject: Re: NetBSD/FreeBSD (pthreads) To: mira!sdsp.mc.xerox.com!leisner@werple.net.au (Marty Leisner) Date: Fri, 20 Oct 1995 11:16:56 +1000 (EST) Cc: hackers@freebsd.org, jb@cimlogic.com.au In-Reply-To: <9510192300.AA03362@willow.mc.xerox.com> from "Marty Leisner" at Oct 19, 95 03:58:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk Marty, > But it does this via (I think...) all I/O being nonblocking, and if > it would block it then run another thread.... That's right. > I haven't looked at the code for a while, but kernel threads would be > much more efficient (if a task blocks on I/O, it blocks inside > the kernel, rather then muxing on select...) I guess kernel threads would be more efficient wrt blocking, but in our application (process control with scan times in 10's of milliseconds), we still see such a performance improvement over separate forked process. > I agree you can implement user-space pthreads efficiently if > multiple processor are compute bound...but this is not > why you have threads... We are using threads for precisely this. Our threads are (amongst other things) executing PLC programs and are not only compute bound, but memory bandwidth limited. Cache has no impact because we always overflow what ever the cache size is. > > Also, each kernel call will need context switches, which slow things > down... The number of kernel calls goes up with a user-space threaded application, and you may treat this as slowing things down, but relative to a set of separate processes performing the same task the speed up is remarkable. > > marty > > > -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 9600 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137 From owner-freebsd-hackers Thu Oct 19 18:31:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA08896 for hackers-outgoing; Thu, 19 Oct 1995 18:31:02 -0700 Received: from werple.net.au (0@werple.mira.net.au [203.9.190.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA08891 for ; Thu, 19 Oct 1995 18:30:54 -0700 Received: from cimaxp1.UUCP (Ucimlogi@localhost) by werple.net.au (8.7/8.7) with UUCP id LAA08945 for hackers@freebsd.org; Fri, 20 Oct 1995 11:03:32 +1000 (EST) Message-Id: <199510200103.LAA08945@werple.net.au> X-Authentication-Warning: werple.net.au: Ucimlogi set sender to cimaxp1!jb using -f Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA17525; Fri, 20 Oct 1995 11:05:30 +1000 From: John Birrell Subject: Re: NetBSD/FreeBSD (pthreads) To: julian@ref.tfs.com (Julian Elischer) Date: Fri, 20 Oct 1995 11:05:29 +1000 (EST) Cc: hackers@freebsd.org, jb@cimlogic.com.au In-Reply-To: <199510192246.PAA23918@ref.tfs.com> from "Julian Elischer" at Oct 19, 95 03:46:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk Julian, > > > I'm curious about why you *need* kernel threads. > > usually it's for several blocking IO streams.. The user space threads implementation fudges blocking IO and this works fine for us. > > > > > If you end up trying to use the MIT threads, watch out! We ended up completely > > retructuring the code to a more sane (IMHO) implementation. > this is the stuff you ended up using right? Yes, we ended up using our restructured version. We've got a customer deadline to meet with $$$ attached, so this was an easy decision to make. > have you forwarded your changes back? No. Instead I've started talking to a few NetBSD folks about making libc support pthreads directly. The MIT implementation has duplicated _many_ of the libc functions, including the assembly language stuff like setjmp. This makes supporting the system (pthreads + opsys) more difficult than it needs to be. So we changed libc to allow for threads. We build it twice, once with a preprocessor definition _THREAD_SAFE and once without it. For the threaded version, a few extra source files are compiled. We always link against libc, never libpthread.a and _then_ libc. The MIT implementation tries to sit on top of a system like FreeBSD/NetBSD. We believe that it should be part of it. Our implementation is now so different to the one from MIT that I doubt they'd be receptive to changes that affect their basic design. [Sorry if I have jumped to the wrong conclusion]. As an example of an area where our design differs, consider handing signals. MIT uses a global set of signal handler definitions. We do this on a thread-by-thread basis. A thread that is interrupted by a signal which it wants to catch, suspends while a signal-handler-thread runs. This thread can do what it believes is blocking IO and it can catch signals (which cause additional signal-handler-threads to run and so on). The scheduler allows threads that are not waiting on signal handler threads to compete against any signal-handler-threads. Our scheduler allows a context switch when the real signal handler function is about to return. Threads are context switched out by another thread doing blocking I/O or by a signal, the most common of which is SIGVTALRM. Another area where we differ from MIT, is in the use of mutexes internally within the threaded library. We believe that mutexes are things that the library provides, but that the low level implementation should not use them. This means that we have stripped the malloc mutex, the file descriptor mutexes, the key-specific mutex etc. We inhibit signals from interrupting the scheduler in zones of code that need to be protected. > > are you doing this under FreeBSD as well? We're a bit behind with FreeBSD. You guys move so quickly... 8-). We've ported all our non-threaded code to FreeBSD (2.0.5R). With the exception of the function in the kernel which locates SYSVSHM segments, there were no problems. (NetBSD fixed SYSVSHM a few months ago. 2.0.5R behaves as NetBSD did). We're currently writing widgets so that we don't rely on Motif. Then all we need is libc in FreeBSD to be ported to support pthreads and we have our factory process monitoring and control product ready to go under FreeBSD. Are you prepared to consider changing the FreeBSD libc to allow the _option_ of building a threaded version? Do you prefer keeping a separate libpthread like MIT builds? Are you using the MIT pthreads under FreeBSD? > > julian > -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 9600 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137 From owner-freebsd-hackers Thu Oct 19 18:34:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA09008 for hackers-outgoing; Thu, 19 Oct 1995 18:34:34 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA09000 for ; Thu, 19 Oct 1995 18:34:31 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA03804; Thu, 19 Oct 1995 18:24:45 -0700 From: Terry Lambert Message-Id: <199510200124.SAA03804@phaeton.artisoft.com> Subject: Re: Bragging rights.. To: mbarkah@hemi.com (Ade Barkah) Date: Thu, 19 Oct 1995 18:24:45 -0700 (MST) Cc: hasty@rah.star-gate.com, dennis@etinc.com, jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: <199510200052.SAA15098@hemi.com> from "Ade Barkah" at Oct 19, 95 06:52:47 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1961 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > There is the small issue of what the telco charges . It costs me about > > $100/month to keep my 128kb ISDN Line up for the whole month and that > > includes my ISP v-site.net . > > > > So what do the telcos usually charge for a fraction of a T1? > > In the order of $500 depending how far away you are from your isp's > POP, plus another $1200 to $1600 to pay the provider (we're talking > 128kbps fractional t1.) Some telcos charge you for a full t1 even > if you only use a fraction of it. > > To bad I can't get ISDN at home for my FreeBSD machine =( =(. > (complain complain U.S. West) You don't want ISDN anyway. In most US West areas (yes, we know you have it better than the rest of us, Colorado!) they charge message unit charges over a certain usage limit, with tarrif provisions for reducing that usage limit to 0 at their option at some future date. This is done with the rationale that you are tying up switching equipment, which you wouldn't be tying up if you were using Frame Relay (packet switched) instead of ISDN (circuit switched) in the first place. The Telco's are hedging their bets, since they want to be able to meter your usage in the future (an unrealistic goal for Frame Relay), and so are really, really pushing ISDN. Consider that with no way to meter calls or destinations, the RBOC can't charge you for in state long distance, and the long distance carriers are reduced to charging the RBOC's based on the size of the pipe they have connected instead of based on who's calling who. A lot of the big LD carriers that are also backbone providers are blocking the usage of "Internet Phone" programs because of this, though they do it by blocking the circuit transport (IRC) arguing bandwidth... MCI and Sprint are prime examples. Makes you want to start your own phone company. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Oct 19 18:46:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA09266 for hackers-outgoing; Thu, 19 Oct 1995 18:46:49 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA09260 for ; Thu, 19 Oct 1995 18:46:45 -0700 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id VAA00552 for freebsd-hackers@freebsd.org; Thu, 19 Oct 1995 21:46:39 -0400 From: Charles Henrich Message-Id: <199510200146.VAA00552@crh.cl.msu.edu> Subject: New format for /etc/magic To: freebsd-hackers@freebsd.org Date: Thu, 19 Oct 1995 21:46:39 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 277 Sender: owner-hackers@freebsd.org Precedence: bulk Here is a new entry for /etc/magic, could whomever please commit? Thanks: 0 string PS-X\ EXE Sony Playstation Binary -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-hackers Thu Oct 19 18:56:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA09676 for hackers-outgoing; Thu, 19 Oct 1995 18:56:34 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA09671 ; Thu, 19 Oct 1995 18:56:30 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id SAA02679; Thu, 19 Oct 1995 18:56:20 -0700 Date: Thu, 19 Oct 1995 18:56:20 -0700 Message-Id: <199510200156.SAA02679@silvia.HIP.Berkeley.EDU> To: ache@astral.msk.su CC: jmz@cabri.obs-besancon.fr, dawes@rf900.physics.usyd.edu.au, hackers@freebsd.org, rich@freebsd.org In-reply-to: Subject: Re: X distribution From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-hackers@freebsd.org Precedence: bulk * I not mean building ideas/algorithms here, but real life * situation. Now I fix XFree port (assume that Satoshi will commit * the fix in near future because it emergency needed) and not shure * that this fix will be passed to another building system (I mean * Rich here). If Rich will builds the system from your port * (and maybe some needed programs from contrib additionly), * this problem can't even occurse. * Rich, please, consider my proposal. As Jean-Marc said, the XFree86 distribution that comes with FreeBSD releases existed long before the x11/XFree "port". In addition to the missing contrib programs, the port lacks the mechanism to pack it in several different packages. Also, the XFree86 .tgz files are not "packages" in the normal senses, they are pure tarfiles. So it's probably more comfortable for Rich to use his own build mechanism, rather than use the one in ports. Maybe we can change this in the future (i.e., not 2.1), as the package installation is becoming an integral part of the installation. For now, I'm only concerned that we are all in the same page. Rich, if you are going to apply this to your XFree86 distribution, I will apply this to the XFree port too (unless Jean-Marc objects), so please let me know what you are going to do. Satoshi From owner-freebsd-hackers Thu Oct 19 19:06:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA10073 for hackers-outgoing; Thu, 19 Oct 1995 19:06:29 -0700 Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA10061 for ; Thu, 19 Oct 1995 19:06:19 -0700 Received: (from mbarkah@localhost) by hemi.com (8.6.11/8.6.9) id UAA15465; Thu, 19 Oct 1995 20:09:50 -0600 From: Ade Barkah Message-Id: <199510200209.UAA15465@hemi.com> Subject: Re: Bragging rights.. To: terry@lambert.org (Terry Lambert) Date: Thu, 19 Oct 1995 20:09:50 -0600 (MDT) Cc: hasty@rah.star-gate.com, dennis@etinc.com, jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: <199510200124.SAA03804@phaeton.artisoft.com> from "Terry Lambert" at Oct 19, 95 06:24:45 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 931 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > To bad I can't get ISDN at home for my FreeBSD machine =( =(. > > (complain complain U.S. West) > > You don't want ISDN anyway. ... [usage charges here] > > This is done with the rationale that you are tying up switching > equipment, which you wouldn't be tying up if you were using Frame > Relay (packet switched) instead of ISDN (circuit switched) in the > first place. Yup... of course, I can't get frame relay into my condo either. =( Too bad, since I'll have a free adtran 64k csu/dsu from the office. So it's the old PPP-over-modem for the FreeBSD box. Load balancing, anyone ? =) (I just asked M.J Karels about this today in class, but he went talking about meta interfaces in the kernel and such.) =) -Ade -------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - www: -------------------------------------------------------------------- From owner-freebsd-hackers Thu Oct 19 19:15:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA10624 for hackers-outgoing; Thu, 19 Oct 1995 19:15:56 -0700 Received: from werple.net.au (werple.mira.net.au [203.9.190.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA10613 for ; Thu, 19 Oct 1995 19:15:45 -0700 Received: from cimaxp1.UUCP (Ucimlogi@localhost) by werple.net.au (8.7/8.7) with UUCP id MAA11995 for hackers@freebsd.org; Fri, 20 Oct 1995 12:08:27 +1000 (EST) Message-Id: <199510200208.MAA11995@werple.net.au> X-Authentication-Warning: werple.net.au: Ucimlogi set sender to cimaxp1!jb using -f Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA16908; Fri, 20 Oct 1995 12:11:07 +1000 From: John Birrell Subject: Re: NetBSD/FreeBSD (pthreads) To: mira!lambert.org!terry@werple.net.au (Terry Lambert) Date: Fri, 20 Oct 1995 12:11:06 +1000 (EST) Cc: hackers@freebsd.org, jb@cimlogic.com.au In-Reply-To: <199510200112.SAA03776@phaeton.artisoft.com> from "Terry Lambert" at Oct 19, 95 06:12:35 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > > >usually it's for several blocking IO streams.. > > > > pthreads handles this... > > No it doesn't. To the thread is does *appear* to block. > > But it does this via (I think...) all I/O being nonblocking, and if > > it would block it then run another thread.... > > This is how it runs, period: It changes blocking operations into > non-blocking operations plus a context switch. > > If you get a real blocking operation (ie: one outside the model, etc.), > then all threads are blocked because the context switcher can't run Our scheduler runs on signals, so any calls outside the model are interrupted and the next thread is run. An example of a blocking call that is outside the pthreads model is msgrcv(). In our implementation, a blocking call to msgrcv() will block for its time slice and then be interrupted by a SIGVTALRM so that the next thread runs. The application has to handle the EINTR that is returned to the thread once it gets to run again. Either that or the application has to be written to use IPC_NOWAIT. Either way requires a compromise. > unless it converts the call. Like fstatfs/statfs on a remote but > down server (yit's not a select()'able operation). This should still be interruptable by a signal. > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 9600 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137 From owner-freebsd-hackers Thu Oct 19 19:44:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA11508 for hackers-outgoing; Thu, 19 Oct 1995 19:44:30 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA11498 for ; Thu, 19 Oct 1995 19:44:26 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id TAA17580; Thu, 19 Oct 1995 19:43:26 -0700 Message-Id: <199510200243.TAA17580@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Terry Lambert cc: hackers@freebsd.org Subject: Re: Bragging rights.. In-reply-to: Your message of "Thu, 19 Oct 1995 18:24:45 PDT." <199510200124.SAA03804@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Oct 1995 19:43:25 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk >>> Terry Lambert said: > A lot of the big LD carriers that are also backbone providers are > blocking the usage of "Internet Phone" programs because of this, > though they do it by blocking the circuit transport (IRC) arguing > bandwidth... MCI and Sprint are prime examples. I wonder how will they block bat my rtpv2 net audio tool :) > Makes you want to start your own phone company. Not a problem with radio spectrum transmitters/receivers also there will be cable modems no matter what the telcos are losing :) Enjoy, Amancio From owner-freebsd-hackers Thu Oct 19 20:17:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA12625 for hackers-outgoing; Thu, 19 Oct 1995 20:17:40 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA12619 for ; Thu, 19 Oct 1995 20:17:29 -0700 Received: from relay-4.mail.demon.net (relay-4.mail.demon.net [158.152.1.64]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id UAA08181 for ; Thu, 19 Oct 1995 20:16:07 -0700 Date: Thu, 19 Oct 1995 20:16:07 -0700 Received: from disperse.demon.co.uk by relay-4.mail.demon.net id msg.ab20482; 20 Oct 95 3:38 +0100 Received: from post.demon.co.uk by relay-2.mail.demon.net id fg29951; 20 Oct 95 3:33 +0100 Received: from relay-2.mail.demon.net by relay-3.mail.demon.net id ac02539; 18 Oct 95 23:52 +0100 Received: from kiss.demon.co.uk by wbsmail.zipmail.co.uk id aa05979; 18 Oct 95 23:52 BST X-Sender: phil@wbsmail.zipmail.co.uk (Unverified) X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-hackers@freebsd.org From: Phil Taylor Subject: Drivers for Allied Telesyn Cards Message-ID: <9510182352.aa05979@wbsmail.zipmail.co.uk> Sender: owner-hackers@freebsd.org Precedence: bulk I have seen that there are drivers in FBSD that support the AT-1700 cards based around the Fujitsu MB8696xA chips. The AT-1500 uses the AMD PCNET ISA chip which has the id AM79C960KC. I deal a lot with ATI and I think they are prepared to send me data on the cards and hoepfully on the AMD chip. What I would like to know is, 1. Does any body know whether the Fujitsu is much different (functionally) from the AMD. 2. Has anyone got direct info on the AMD chip.. 3. (and probably the most important) As this is my first attempt at hacking FBSD drivers I will need as much help as I can get, I am a reasonably accomplished C programmer including quite a bit of low level programming under DOS, but this is my first REAL unix project, so could someone please let me know at least the procedure for submitting code and be prepared for a flood of eMails from me when it doesn't work 8-) I would really like to get into kernel/driver hacking and as I use a lot of ATI kit it is in my interest to get it working. Cheers Phil p.s. Yes I have tried the fe driver and had a look at if_fe.c, it didn't detect the card and it seems that when the driver was written there wasn't much info on the AT-1700, I can also try and get info on this and tie up some of the loose ends in if_fe.c if this would be any use. ------------------------------------- Tear Here ------------------------------------- Phil Taylor Lan Systems phil@zipmail.co.uk 150 London Road, Leicester ENGLAND, LE2 1AN Network & Internet Consultancy Tel : +44 (0)116 255 9961 Software & Hardware Fax : +44 (0)116 255 8861 " Just because I'm Paranoid, Doesn't mean the world isn't out to get me " From owner-freebsd-hackers Thu Oct 19 21:06:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA14010 for hackers-outgoing; Thu, 19 Oct 1995 21:06:12 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA14002 for ; Thu, 19 Oct 1995 21:05:59 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id OAA17324; Fri, 20 Oct 1995 14:04:38 +0930 From: Michael Smith Message-Id: <199510200434.OAA17324@genesis.atrad.adelaide.edu.au> Subject: Re: Drivers for Allied Telesyn Cards To: phil@zipmail.co.uk (Phil Taylor) Date: Fri, 20 Oct 1995 14:04:38 +0930 (CST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <9510182352.aa05979@wbsmail.zipmail.co.uk> from "Phil Taylor" at Oct 19, 95 08:16:07 pm Content-Type: text Content-Length: 717 Sender: owner-hackers@freebsd.org Precedence: bulk Phil Taylor stands accused of saying: > I have seen that there are drivers in FBSD that support the AT-1700 > cards based around the Fujitsu MB8696xA chips. > > The AT-1500 uses the AMD PCNET ISA chip which has the id AM79C960KC. This should already be supported by the lnc driver. If not, that's where you should be working. > Phil -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Thu Oct 19 21:08:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA14208 for hackers-outgoing; Thu, 19 Oct 1995 21:08:27 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA14196 for ; Thu, 19 Oct 1995 21:08:16 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id OAA14265; Fri, 20 Oct 1995 14:05:36 +1000 Date: Fri, 20 Oct 1995 14:05:36 +1000 From: Bruce Evans Message-Id: <199510200405.OAA14265@godzilla.zeta.org.au> To: bde@zeta.org.au, mark@grondar.za Subject: Re: Creating a /dev/random Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >Here is how far I have gotten with creating a /dev/random. >Please have a look at the following patches, and let me know what you >think. >... > o I thought it best to place my interrupt hooks where I did, instead > of where you suggested, as I decided I wanted to be as close to > the interrupt code as I could get. Also the `unit' you suggested I > use to fiddle the irq passing would not work - it did not have the > right range of values (it would typically obly be 0, wth the occaisional > 1 or 2) My method avoids extra overhead for the interrupts that aren't hooked. I said to replace the `unit' number by the interrupt number in intr_unit[] and load the original unit number in the dispatch function before calling the interrupt handler. > o I have yet to write some kind of IOCTL to set this interrupt selector. > (Would an ioctl be the right way? Is there some precedent I could > follow? Yes. spkr.c: spkrioctl() would be a good example if it was written right. Correct the following stylistic and real bugs in it to get a good example: 1) the formatting is nonstandard. 2) after it has decided that it doesn't handle minor(dev), it should return ENODEV, not ENXIO. You will have to add a memioctl() function and return ENODEV from it for all except the new /dev/random minor. 3) it should use switch(cmd) instead of a bunch of `if (cmd == ...)' statements. 4) the copyin() of the data is bogus and may fail. In BSD, the size of the data is encoded in the command value and the copyin() is done at a higher level. The copyin() of the driver does a copy of kernel data to kernel data and may fail if copyin() only works for user to kernel copies. The i386 copyin() probably works for kernel to kernel copies too. 5) after it has decided that it doesn't handle the command, it should return ENOTTY, not EINVAl. EINVAL is for appropriate for invalid data in a supported command. The interface could use a bitmap of the interrupts to select, but this would be unportable (see recent mail about select()) and speed isn't important (unlike for select()). It should probably use the number of one interrupt, a select command and a deselect command. >diff -udr --exclude=compile sys.ORG/i386/conf/files.i386 sys/i386/conf/files.i386 > ... >+i386/isa/random.c standard Should be optional. Perhaps `optional random device-driver'. >diff -udr --exclude=compile sys.ORG/i386/i386/machdep.c sys/i386/i386/machdep.c >--- sys.ORG/i386/i386/machdep.c Thu Oct 12 12:34:03 1995 >+++ sys/i386/i386/machdep.c Thu Oct 19 20:44:13 1995 >@@ -126,6 +126,7 @@ > #include > #include > #include >+#include Does it really have isa dependencies? The other isa includes in machdep.c are bogus too. >diff -udr --exclude=compile sys.ORG/i386/isa/vector.s sys/i386/isa/vector.s >... >@@ -195,6 +205,8 @@ > outb %al,$icu+1 ; \ > sti ; /* XXX _doreti repeats the cli/sti */ \ > MEXITCOUNT ; \ >+ /* Add this interrupt to the pool of entropy */ \ >+ ADDENTROPY(irq_num) ; \ > /* We could usually avoid the following jmp by inlining some of */ \ > /* _doreti, but it's probably better to use less cache. */ \ > jmp _doreti ; \ The addition should be before the MEXITCOUNT for correct profiling (in my version of profiling, MEXITCOUNT is non-null and must be placed immediately before all jmps). It should probably be even earlier, immediately after the call to the interrupt handler, so that it is called while interrupts for the device are still masked in the ICU. Placing it later doesn't improve latency, because device interrupts are still masked in software. Bruce From owner-freebsd-hackers Thu Oct 19 22:11:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA15835 for hackers-outgoing; Thu, 19 Oct 1995 22:11:03 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA15829 for ; Thu, 19 Oct 1995 22:11:00 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id WAA00254 for ; Thu, 19 Oct 1995 22:10:19 -0700 Message-Id: <199510200510.WAA00254@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 to: hackers@freebsd.org Subject: (audio tools) Re: Bragging rights.. In-reply-to: Your message of "Thu, 19 Oct 1995 19:43:25 PDT." <199510200243.TAA17580@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Oct 1995 22:10:18 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk >>> "Amancio Hasty Jr." said: > >>> Terry Lambert said: > > A lot of the big LD carriers that are also backbone providers are > > blocking the usage of "Internet Phone" programs because of this, > > though they do it by blocking the circuit transport (IRC) arguing > > bandwidth... MCI and Sprint are prime examples. > > I wonder how will they block bat my rtpv2 net audio tool :) > You can now add "vat" to the native port tools which the telcos will have to block :) At any rate Van Jacobson has now finally release the sources for vat. Amancio From owner-freebsd-hackers Thu Oct 19 22:12:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA15903 for hackers-outgoing; Thu, 19 Oct 1995 22:12:33 -0700 Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA15896 for ; Thu, 19 Oct 1995 22:12:27 -0700 Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id KAA02495; Fri, 20 Oct 1995 10:12:37 +0500 From: "Serge A. Babkin" Message-Id: <199510200512.KAA02495@hq.icb.chel.su> Subject: Re: I can't apply your ep patches! :-( To: jlc@kepler.whats.att.com (Johanan L. Codona) Date: Fri, 20 Oct 1995 10:12:36 +0500 (GMT+0500) Cc: hackers@freebsd.org In-Reply-To: <199510191953.PAA03428@kepler.whats.att.com> from "Johanan L. Codona" at Oct 19, 95 03:53:24 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 758 Sender: owner-hackers@freebsd.org Precedence: bulk > > Serge, > > Are you using a different version of patch, or am I supposed to do > something different? > > $ patch < ep0.patch2 > Hmm... Looks like a new-style context diff to me... > The text leading up to this was: > -------------------------- > |*** /usr/src-cur/sys/i386/isa/if_ep.c Mon Oct 16 17:40:39 1995 > |- --- if_ep.c Wed Oct 18 12:30:37 1995 > -------------------------- > Patching file if_ep.c using Plan A... > patch: **** unexpected end of hunk at line 14 Oh! I forgot to remove this hunk with $Id$ string ! Everybody trying to apply this patch, remove it please ! I'm sorry :-( Serge Babkin ! (babkin@hq.icb.chel.su) ! Headquarter of Joint Stock Commercial Bank "Chelindbank" ! Chelyabinsk, Russia From owner-freebsd-hackers Thu Oct 19 22:48:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA16665 for hackers-outgoing; Thu, 19 Oct 1995 22:48:58 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA16644 for ; Thu, 19 Oct 1995 22:48:25 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id PAA17640; Fri, 20 Oct 1995 15:51:08 +0930 From: Michael Smith Message-Id: <199510200621.PAA17640@genesis.atrad.adelaide.edu.au> Subject: Re: Bragging rights.. To: davidg@Root.COM Date: Fri, 20 Oct 1995 15:51:08 +0930 (CST) Cc: root@spiffy.cybernet.com, hackers@FreeBSD.org In-Reply-To: <199510192337.QAA00227@corbin.Root.COM> from "David Greenman" at Oct 19, 95 04:37:01 pm Content-Type: text Content-Length: 1724 Sender: owner-hackers@FreeBSD.org Precedence: bulk David Greenman stands accused of saying: > >As a slightly interested party, I'd like to ask: > > > >As mentioned recently on -hackers, isn't it possilbe to up the rate of the serial > >chip simply by doubling (or quadding) the rate of the xtal driving the chip? > >Many (most?) 16550 chips should be able to handle a Fmax higher than they are being > >driven, and with 16 byte FIFOS (set to trigger at 14 bytes), the interrupt overhead > >would not necessarily be increased. > > > >Is the same xtal trick applicable to sync serial, to get 32 KBytes/second @256000 > >bits/sec (as opposed to 28.8 KBytes/sec async serial @230400 bits/sec)? > > Apparantly, *some* 16550 UARTs will do this, but as far as I know, this > would be overclocking most versions out there and might result in the part > overheating (or simply not working at 230K baud). The PC16550D (The "reference" part for 16550's) is specified to a 24MHz input clock. The standard clock reference for this part in a PC is 1.8MHz. Decent serial card vendors (eg. Quatech) offer jumper-selectable clock dividers to allow you to pick your desired clock rate. I would have a hard time believing that a modern CMOS '550 clone wouldn't handle a 3.6MHz input clock. Regardless, the question was about sync serial speeds. You don't do sync with a '550, so the point is moot. > -DG -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Thu Oct 19 23:08:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA17279 for hackers-outgoing; Thu, 19 Oct 1995 23:08:14 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA17274 for ; Thu, 19 Oct 1995 23:08:10 -0700 Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id XAA26619; Thu, 19 Oct 1995 23:06:37 -0700 Message-ID: <30873C6D.59E2B600@FreeBSD.org> Date: Thu, 19 Oct 1995 23:06:37 -0700 From: "Jordan K. Hubbard" X-Mailer: Mozilla 2.0b1 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: dennis CC: Joe Greco , hackers@FreeBSD.org Subject: Re: Bragging rights.. References: <199510200052.UAA29399@etinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk dennis wrote: > Actually, Dennis started this thread by trying to get a price reference for > the Async solution that Jordan referred to....I did not start it by saying > that sync is better than async. My point was that if for about the same > money you can have a more flexible solution that will use less of your CPU > it is worth considering. Unlike most of you, my perspective is All true, and now that we've established that the basic cost of entry (not counting the line itself) for a TA and a serial card is about $650 (or 2X if you're responsible for both sides), the final question simply remains as to whether the cost *increment* to get that last 38.9% or so is worth it. I'm not saying it is or isn't either way, and 38.9% is certainly nothing to sneeze at (that's basically one V.34 modem's worth of pipe you're *losing*), but if sync serial cards cost half again what the TAs cost, well, that's a steep knee in the price/performance curve too! :( That's why I was optimistic about the ISDN card solutions: They're cheaper than TAs, they give you your full 128K, and when drivers become available (and they will, I am confident) they are just as plug-n-play as a TA to anyone reasonably competent with a screwdriver. People are plugging in their own VGA cards, I suppose they can handle an ISDN card! :) However, you've already said that you don't like the ISDN cards and consider them too limited, so we're back to the cost argument again. Maybe what's needed is a low-end sync serial card that doesn't cost much more than $150 and does everything up to 512K or so on one port. Target it at the end user who only has (and needs) one connection and might go frac-T1 someday but will most likely be pottering around at 128Kb for some time. Let's face it, most of us will never have a T1 at home. We will dream about it, but that's going to be the premium business pipe for some time and I don't expect it to fall within the reach of mere mortals anytime soon! If I'm even going 256K by the end of '96 I'll be pretty happy. So I would have need for a pair of sync-serial cards that were cheap and would do everything up to this data rate for at least 2 years, and that's all the service life I expect from *any* computer related component these days.. :-) I'm not an ISP, I'm an end-user and my needs and budget are rather different than the market you probably deal with ordinarily.. -- Jordan From owner-freebsd-hackers Thu Oct 19 23:44:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA17895 for hackers-outgoing; Thu, 19 Oct 1995 23:44:43 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA17886 for ; Thu, 19 Oct 1995 23:44:04 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id IAA28575; Fri, 20 Oct 1995 08:43:11 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id IAA01491; Fri, 20 Oct 1995 08:43:10 +0200 Message-Id: <199510200643.IAA01491@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: Bruce Evans cc: hackers@FreeBSD.org Subject: Re: Creating a /dev/random Date: Fri, 20 Oct 1995 08:43:10 +0200 From: Mark Murray Sender: owner-hackers@FreeBSD.org Precedence: bulk > > o I thought it best to place my interrupt hooks where I did, instead > > of where you suggested, as I decided I wanted to be as close to > > the interrupt code as I could get. Also the `unit' you suggested I > > use to fiddle the irq passing would not work - it did not have the > > right range of values (it would typically obly be 0, wth the occaisional > > 1 or 2) > > My method avoids extra overhead for the interrupts that aren't hooked. > I said to replace the `unit' number by the interrupt number in intr_unit[] > and load the original unit number in the dispatch function before calling > the interrupt handler. There is a problem with this. The interrupt handler is called with a unit number, which is non-unique. There is no way to get back to the original interrupt handler. (you suggested:) > I think you will need to hook selected interrupt handlers to get dynamic > interrupt information. INTR() is too static. The following would almost > work: > > void init_interrupt_randomness(void) { > for (each irq of interest) { > prev_intr_handler[irq] = intr_handler[irq]; > prev_intr_unit[irq] = intr_unit[irq]; > disable_intr(); > intr_handler[irq] = add_interrupt_randomness; > intr_unit[irq] = irq; > enable_intr(); > } > } > > void add_interrupt_randomness(int irq) { <-- units, not irq's > static u_char busy; > > disable_intr(); > if (busy) > enable_intr(); > else { > busy = TRUE; > enable_intr(); > do_things(irq); > busy = FALSE; > } > (*prev_intr_handler[irq])(prev_intr_unit[irq]); <=== won't work as units are mostly small numbers > } > > o I have yet to write some kind of IOCTL to set this interrupt selector. > > (Would an ioctl be the right way? Is there some precedent I could > > follow? > > Yes. spkr.c: spkrioctl() would be a good example if it was written right. > Correct the following stylistic and real bugs in it to get a good example: Great! Thanks.. [I like the example - "except for this list of bugs, this is the route to follow" ;-)] > >diff -udr --exclude=compile sys.ORG/i386/conf/files.i386 sys/i386/conf/files .i386 > > ... > >+i386/isa/random.c standard > > Should be optional. Perhaps `optional random device-driver'. I would rather make it a permanent fixture. When random.c is compiled the object file is about 5k, not much for the bloatists to complain about ;-). If software developers like Netscrape could count on this device being present, then they would use it. If it is optional, it may as well be not there. These are Ts'o's sentiments as well. Right now there are #ifdef DEVRANDOM constructs around the code, which I would like to remove when it is stable. > >diff -udr --exclude=compile sys.ORG/i386/i386/machdep.c sys/i386/i386/machde p.c > >--- sys.ORG/i386/i386/machdep.c Thu Oct 12 12:34:03 1995 > >+++ sys/i386/i386/machdep.c Thu Oct 19 20:44:13 1995 > >@@ -126,6 +126,7 @@ > > #include > > #include > > #include > >+#include > > Does it really have isa dependencies? The other isa includes in machdep.c > are bogus too. is this the wrong place to put this header? It is a short file containing necessary function prototypes. > >diff -udr --exclude=compile sys.ORG/i386/isa/vector.s sys/i386/isa/vector.s > >... > >@@ -195,6 +205,8 @@ > > outb %al,$icu+1 ; \ > > sti ; /* XXX _doreti repeats the cli/sti */ \ > > MEXITCOUNT ; \ > >+ /* Add this interrupt to the pool of entropy */ \ > >+ ADDENTROPY(irq_num) ; \ > > /* We could usually avoid the following jmp by inlining some of */ \ > > /* _doreti, but it's probably better to use less cache. */ \ > > jmp _doreti ; \ > > The addition should be before the MEXITCOUNT for correct profiling (in my > version of profiling, MEXITCOUNT is non-null and must be placed immediately > before all jmps). It should probably be even earlier, immediately after > the call to the interrupt handler, so that it is called while interrupts > for the device are still masked in the ICU. Placing it later doesn't > improve latency, because device interrupts are still masked in software. Will do. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-hackers Fri Oct 20 02:07:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA21836 for hackers-outgoing; Fri, 20 Oct 1995 02:07:35 -0700 Received: from fgate.flevel.co.uk (fgate.flevel.co.uk [194.6.101.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA21829 for ; Fri, 20 Oct 1995 02:07:25 -0700 Received: (from freebsd@localhost) by fgate.flevel.co.uk (8.6.11/8.6.9) id KAA04027; Fri, 20 Oct 1995 10:10:20 +0100 Date: Fri, 20 Oct 1995 10:10:19 +0100 (BST) From: freebsd To: hackers@freebsd.org cc: graham@flevel.co.uk Subject: Duplicating whole disks In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Hi >From time to time we need to make exact copies of a large number of hard drives partitioned with freebsd. The drives are external SCSIs. Opinions please on the most efficient and fastest method. Would you please Cc: graham@flevel.co.uk Thanks v. much From owner-freebsd-hackers Fri Oct 20 03:27:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA23956 for hackers-outgoing; Fri, 20 Oct 1995 03:27:46 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA23951 for ; Fri, 20 Oct 1995 03:27:42 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id FAA29169; Fri, 20 Oct 1995 05:24:48 -0500 From: Joe Greco Message-Id: <199510201024.FAA29169@brasil.moneng.mei.com> Subject: Re: Bragging rights.. To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Fri, 20 Oct 1995 05:24:46 -0500 (CDT) Cc: davidg@root.com, root@spiffy.cybernet.com, hackers@freebsd.org In-Reply-To: <199510200621.PAA17640@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 20, 95 03:51:08 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > > Apparantly, *some* 16550 UARTs will do this, but as far as I know, this > > would be overclocking most versions out there and might result in the part > > overheating (or simply not working at 230K baud). > > The PC16550D (The "reference" part for 16550's) is specified to a 24MHz input > clock. And here I always thought it was the National Semiconductor part that was the "reference" part, because the 16550 was originally their fault. I still have original 16550's around that bear a rather unusual patent marking on them (I can't think of another component where that was done)... anyways, the information I posted and have posted in the past is from NatSemi data books. The NS16550AF is rated at 8 MHz. The NS16C551 is rated at 24 MHz. YMMV depending on the mfr of your particular brand of 16550... however it does look like it is probably safe to at least doubleclock just about any 16550. > The standard clock reference for this part in a PC is 1.8MHz. > Decent serial card vendors (eg. Quatech) offer jumper-selectable clock > dividers to allow you to pick your desired clock rate. I have yet to see this on any reasonably-priced card :-( Fortunately, it's a cheap upgrade to do if you're handy with a soldering iron.. > I would have a hard time believing that a modern CMOS '550 clone wouldn't > handle a 3.6MHz input clock. Yes. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Fri Oct 20 04:33:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA29839 for hackers-outgoing; Fri, 20 Oct 1995 04:33:30 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA29834 for ; Fri, 20 Oct 1995 04:33:28 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id GAA29189; Fri, 20 Oct 1995 06:32:24 -0500 From: Joe Greco Message-Id: <199510201132.GAA29189@brasil.moneng.mei.com> Subject: Re: Bragging rights.. To: dennis@etinc.com (dennis) Date: Fri, 20 Oct 1995 06:32:24 -0500 (CDT) Cc: hackers@freebsd.org In-Reply-To: <199510200052.UAA29399@etinc.com> from "dennis" at Oct 19, 95 08:52:48 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > Joe Greco says..... > > >Dennis started this thread on the assertion that his sync serial cards can > >do very high speeds quite easily :-) > > Actually, Dennis started this thread by trying to get a price reference for > the Async solution that Jordan referred to....I did not start it by saying > that sync is better than async. Okay, the former is true, the latter however was not implied. "Dennis _continued_ this thread on the assertion that his sync serial cards can do very high speeds quite easily" .... > My point was that if for about the same > money you can have a more flexible solution that will use less of your CPU > it is worth considering. I agree (but fail to see the "for about the same money" portion of this statement in your product). > Unlike most of you, my perspective is > marketability....not necessarily your (wrong) opinion that async is just as > good. You haven't been reading. I've clearly stated that there is a performance penalty (processing overhead, which generally falls into the category of interrupts) associated with async. There are both benefits and disadvantages. The benefits include the fact that I can go down to Moe's Computers a few blocks down the road and pick up a 16550 solution, the fact that "everybody" speaks async RS232, it's quite reasonably priced, and it's a longtime PC standard. The disadvantages are that at higher data rates it starts to eat CPU, and it's async. > If its not cheaper, which has always been the sole selling point for > async, then it's a no-brainer. Yes, I agree. But the way I count it, it's cheaper by about $370 per side (or $740 per solution) - assuming your card is $400 and a standard _dual_ 16550 card is $30ish (I do not wish to bicker over numbers however). (I notice I've been inadvertently flipping back and forth between wholesale and street prices, I'll try to stick to street prices, sorry folks.. I just happen to do most business at wholesale prices) That's quite a sell for your average consumer of PC grade systems. You can get a cheap V.34 solution (internal generic w/ 16550's) for about $110 total per side. Now you tell this guy who sees this that he can go ISDN for around $275 (Motorola Bitsurfer ext) plus $30 for a 16550, and maybe he's not happy about an extra $195, plus a more expensive monthly ISDN bill, but the total cost isn't sooooo much more than the V.34 solution and he's sold the first time he runs Netscape. He's happy, though, because he can call most places that support ISDN, and his ISP just charges him for greater bandwidth on an async terminal support. So now Dennis tries to come along and sell him a sync serial solution. The guy now forks out $400 for a sync serial card. He hooks it up and finds he can't connect to his ISP. His ISP tells him it'll be an extra couple hundred bucks a month to run their end on sync serial. So he's pissed. Then he finds out he can't call anywhere else either, because no one supports it. So he has now paid $675 for the solution (assuming the Bitsurfer can do sync serial), he HAS the extra bandwidth offered by sync serial, but he's paying several hundred dollars a month for the privilege, and he can only use it for his Internet connection. Six months down the road when he gets tired of it all, and he decides to drop the Internet thing, he finds out he can't even use his sync serial card for his mouse or printer. Cost analysis: $305 for async solution that can do 11520 bytes/sec. $675 for sync solution that can do 14400 bytes/sec. You are paying 2.2x the cost for 1.25x the throughput. In the real world: This will fly just about as well as 16.8K and 19.2K modems did. They're great if you _need_ them. But they're rotten for general public consumption. You can have the greatest, most technically elegant solution in the world. It does not guarantee you success, and it does not guarantee that people will buy it on technical merits. Look at the corpses of companies that have had great technically innovative products that went nowhere. Now look at your average PC - the grungy architecture that survived because it was quick, dirty, and cheap. Dennis, I think you have a _great_ product! This was never questioned. However, that's not the point of all of what I just described. Going back to this statement: > Unlike most of you, my perspective is > marketability....not necessarily your (wrong) opinion that async is just as > good. The marketability perspective I see is that you have a great niche product that can't be beat - within its niche. However, if you wish to butt heads with async, you're in for a real uphill battle. Async is standard. Async is substantially cheaper. Async is available at the corner store. I would not argue that async is just as good as sync - on technical merits. However, from a marketing perspective, I contend that async is _NOT_ "just as good as" sync - it's BETTER. If your marketing department thinks otherwise, you need a new marketing department. And if my opinion is wrong, I'd like to know which aisle the sync serial cards are in at CompUSA... the sales droids don't have a clue. > I have a 386DX/40 routing between a > >T1 (1.544Mb/s) and an Ethernet and it handles average mixes of traffic > >without any trouble (it runs into problems if you start saturating the T1 > >with small packets however). It is QUITE impressive :-) I don't think > >you'd need to do any crystal switches to do what you describe, since the > >board is designed to be quite flexible. However, you are probably limited to > >packet modes such as PPP (Dennis? I am extrapolating here, any solid > >info? I was never able to access raw data streams, although I only looked > >briefly) > > Its limited to whatever I wrote for it so far. There's not much market for > raw data streams. Agreed :-) > We can run 2 dos boxes back to back at 4mbs and run all > day. The overruns you're seeing with small packets is a FreeBSD/CPU power > issue in processing IP packets, and can be linearly corrected by increasing > CPU power...the capabilities are limited only by what unix can handle as the > per packet latency is fairly high, particularly on a slow box. So. From a marketing perspective.... if async is too slow due to processing power, your contention is go sync because it's essentially offloaded I/O.... if things are still too slow then get a faster box.... I know the first thing my marketing dep't would point out is to cut out the intermediate step and just get the faster box right away, since it will cost about the same as doing the intermediate step. Sorry, couldn't resist :-) (for those just joining the party, please note that I am a satisfied ET customer, and definitely would buy their products again, I am just having a bit of trouble swallowing this particular line of reasoning that Dennis is proposing :-) ) ... JG From owner-freebsd-hackers Fri Oct 20 04:38:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA29960 for hackers-outgoing; Fri, 20 Oct 1995 04:38:53 -0700 Received: from shell.monmouth.com (pechter@shell.monmouth.com [205.164.220.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA29954 for ; Fri, 20 Oct 1995 04:38:51 -0700 Received: (from pechter@localhost) by shell.monmouth.com (8.6.12/8.6.12) id HAA20085 for FreeBSD-hackers@freebsd.org; Fri, 20 Oct 1995 07:40:10 -0400 From: Bill/Carolyn Pechter Message-Id: <199510201140.HAA20085@shell.monmouth.com> Subject: anyone see freeing free vnode in -stable To: FreeBSD-hackers@freebsd.org (FreeBSD-hackers) Date: Fri, 20 Oct 1995 07:40:10 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 576 Sender: owner-hackers@freebsd.org Precedence: bulk I've been crashing about once a week with freeing free vnode. I'll get a dump next time. This is with -stable from Oct 12 or so. I'll sup the latest and make world this weekend. Hardware 486 isa bus Micronics motherboard w/8mb and adaptec 1542. Bill ------------------------------------------------------------------------------- Bill Pechter/Carolyn Pechter | The postmaster always pings twice. Lakewood MicroSystems | 17 Meredith Drive, 908-389-3592 | Tinton Falls, NJ 07724 pechter@shell.monmouth.com | From owner-freebsd-hackers Fri Oct 20 05:15:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA00587 for hackers-outgoing; Fri, 20 Oct 1995 05:15:09 -0700 Received: from Relay1.Austria.EU.net (relay1.Austria.EU.net [192.92.138.47]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA00581 for ; Fri, 20 Oct 1995 05:15:01 -0700 From: marino.ladavac@aut.alcatel.at Received: from aut.alcatel.at (dnisun.aut.alcatel.at) by Relay1.Austria.EU.net with SMTP id AA21815 (5.67b/IDA-1.5 for ); Fri, 20 Oct 1995 13:08:55 +0100 Received: from atuhc16 by aut.alcatel.at (4.1/SMI-4.1/AAA-1.29/main) id AA26365; Fri, 20 Oct 95 13:08:48 +0100 Message-Id: <9510201208.AA26365@atuhc16.aut.alcatel.at> Received: by atuhc16 (1.38.193.4/16.2) id AA06319; Fri, 20 Oct 1995 13:08:44 +0100 Subject: Re: NetBSD/FreeBSD (pthreads) To: jb%cimaxp1@werple.net.au (John Birrell) Date: Fri, 20 Oct 95 13:08:43 MET Cc: hackers@freebsd.org In-Reply-To: <199510200208.MAA11995@werple.net.au>; from "John Birrell" at Oct 20, 95 12:11 (noon) Mailer: Elm [revision: 70.85] Sender: owner-hackers@freebsd.org Precedence: bulk > > If you get a real blocking operation (ie: one outside the model, etc.), > > then all threads are blocked because the context switcher can't run > Our scheduler runs on signals, so any calls outside the model are interrupted > and the next thread is run. An example of a blocking call that is outside > the pthreads model is msgrcv(). In our implementation, a blocking call to > msgrcv() will block for its time slice and then be interrupted by a SIGVTALRM > so that the next thread runs. The application has to handle the EINTR that is > returned to the thread once it gets to run again. Either that or the > application has to be written to use IPC_NOWAIT. Either way requires a > compromise. Are you sure that the virtual timer keeps running when process is blocked? I would think not. This means that you shouldn't be able to use SIGVTALRM to interrupt this sort of calls. You would have to jacket them (within the pthread library, hopefully) and activate normal timer and await SIGALRM instead. Is this what you have done in your pthread lib rewrite? > > unless it converts the call. Like fstatfs/statfs on a remote but > > down server (yit's not a select()'able operation). > This should still be interruptable by a signal. > -- > John Birrell CIMlogic Pty Ltd > jb@cimlogic.com.au 119 Cecil Street > Ph +61 3 9690 9600 South Melbourne Vic 3205 > Fax +61 3 9690 6650 Australia > Mob +61 18 353 137 /Alby From owner-freebsd-hackers Fri Oct 20 05:23:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA00741 for hackers-outgoing; Fri, 20 Oct 1995 05:23:04 -0700 Received: from Relay1.Austria.EU.net (relay1.Austria.EU.net [192.92.138.47]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA00736 for ; Fri, 20 Oct 1995 05:22:56 -0700 From: marino.ladavac@aut.alcatel.at Received: from aut.alcatel.at (dnisun.aut.alcatel.at) by Relay1.Austria.EU.net with SMTP id AA22165 (5.67b/IDA-1.5 for ); Fri, 20 Oct 1995 13:22:09 +0100 Received: from atuhc16 by aut.alcatel.at (4.1/SMI-4.1/AAA-1.29/main) id AA26512; Fri, 20 Oct 95 13:21:59 +0100 Message-Id: <9510201221.AA26512@atuhc16.aut.alcatel.at> Received: by atuhc16 (1.38.193.4/16.2) id AA06329; Fri, 20 Oct 1995 13:22:07 +0100 Subject: Re: NetBSD/FreeBSD (pthreads) To: jb%cimaxp1@werple.net.au (John Birrell) Date: Fri, 20 Oct 95 13:22:07 MET Cc: hackers@freebsd.org In-Reply-To: <199510200103.LAA08945@werple.net.au>; from "John Birrell" at Oct 20, 95 11:05 am Mailer: Elm [revision: 70.85] Sender: owner-hackers@freebsd.org Precedence: bulk > > have you forwarded your changes back? > No. Instead I've started talking to a few NetBSD folks about making libc > support pthreads directly. The MIT implementation has duplicated _many_ of > the libc functions, including the assembly language stuff like setjmp. This > makes supporting the system (pthreads + opsys) more difficult than it needs > to be. So we changed libc to allow for threads. We build it twice, once with a > preprocessor definition _THREAD_SAFE and once without it. For the threaded > version, a few extra source files are compiled. We always link against libc, > never libpthread.a and _then_ libc. The MIT implementation tries to sit on top > of a system like FreeBSD/NetBSD. We believe that it should be part of it. Amen! Or at least parallel to libc, on the same level (similar to libcrypt approach.) > Our implementation is now so different to the one from MIT that I doubt they'd > be receptive to changes that affect their basic design. [Sorry if I have jumped > to the wrong conclusion]. As an example of an area where our design differs, > consider handing signals. MIT uses a global set of signal handler definitions. > We do this on a thread-by-thread basis. A thread that is interrupted by a > signal which it wants to catch, suspends while a signal-handler-thread runs. > This thread can do what it believes is blocking IO and it can catch signals > (which cause additional signal-handler-threads to run and so on). The scheduler > allows threads that are not waiting on signal handler threads to compete > against any signal-handler-threads. Our scheduler allows a context switch when > the real signal handler function is about to return. Threads are context > switched out by another thread doing blocking I/O or by a signal, the most > common of which is SIGVTALRM. > Another area where we differ from MIT, is in the use of mutexes internally > within the threaded library. We believe that mutexes are things that the > library provides, but that the low level implementation should not use them. > This means that we have stripped the malloc mutex, the file descriptor > mutexes, the key-specific mutex etc. We inhibit signals from interrupting the > scheduler in zones of code that need to be protected. This partially answers my question from another post. Please note that the MIT pthreads (recent versions thereof) do it in a similar way on a platform that does not support kernel level threads. Perhaps the use/nonuse of mutices internally should be a build-time option. > > > > are you doing this under FreeBSD as well? > We're a bit behind with FreeBSD. You guys move so quickly... 8-). > We've ported all our non-threaded code to FreeBSD (2.0.5R). With the exception > of the function in the kernel which locates SYSVSHM segments, there were no > problems. (NetBSD fixed SYSVSHM a few months ago. 2.0.5R behaves as NetBSD > did). We're currently writing widgets so that we don't rely on Motif. Then all > we need is libc in FreeBSD to be ported to support pthreads and we have our > factory process monitoring and control product ready to go under FreeBSD. > Are you prepared to consider changing the FreeBSD libc to allow the _option_ > of building a threaded version? Do you prefer keeping a separate libpthread > like MIT builds? Are you using the MIT pthreads under FreeBSD? I can speak only of myself, as I am definitely no project member. Yes, I do. I would also be very interested in making the FreeBSD libc thread safe or multithreaded as well. Keeping the library parallel but separate from libc has its own merits, though. Especially during development thereof. Any (other) takers? /Alby > > > > julian > > > -- > John Birrell CIMlogic Pty Ltd > jb@cimlogic.com.au 119 Cecil Street > Ph +61 3 9690 9600 South Melbourne Vic 3205 > Fax +61 3 9690 6650 Australia > Mob +61 18 353 137 From owner-freebsd-hackers Fri Oct 20 06:14:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA02100 for hackers-outgoing; Fri, 20 Oct 1995 06:14:07 -0700 Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA02094 for ; Fri, 20 Oct 1995 06:14:03 -0700 Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id JAA00868; Fri, 20 Oct 1995 09:10:43 -0400 Date: Fri, 20 Oct 1995 09:10:43 -0400 (EDT) From: "Ron G. Minnich" To: Julian Elischer cc: John Birrell , mira!sdsp.mc.xerox.com!leisner@werple.net.au, hackers@freebsd.org, jb@cimlogic.com.au Subject: Re: NetBSD/FreeBSD (pthreads) In-Reply-To: <199510192246.PAA23918@ref.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk I implemented a simple version of plan9 rfork() a little while ago (well, a year ago). You could rfork and end up with shared data space and file table. I also implemented a very simple lock/unlock primitive that was far more efficient than system v semaphores, since in the common case (no contention for a lock) there's no jump to the kernel to wake up other procs when you acquire or free a lock. Between these two things you can do a lot: share data, share locked structures, share open files, etc. I can do all of what i commonly do with kernel threads on, e.g., Irix. In fact I implemented a simple user-space distributed shared memory with these basic parts: on sgi's i used their kernel threads/kernel mutex code, on freebsd i used rfork/lock code i built. For my money this is about as good as kernel threads. There's not the additional complexity in the kernel (have you ever seen what LWP did to sunos? No? good.). This code has been available gratis for a year. I can't convince anyone to pull it into core for netbsd or freebsd, but I'll make the offer again: you want it, let me know. The code, btw, is less than 100 lines for each change. In fact the fastlock code is something like 25 lines. I've implemented them as LKMs and directly as part of the kernel. ron Ron Minnich |Like a knife through Daddy's heart: rminnich@earth.sarnoff.com |"Don't make fun of Windows, daddy! It takes care (609)-734-3120 | of all my files and it's reliable and I like it". From owner-freebsd-hackers Fri Oct 20 06:57:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA03437 for hackers-outgoing; Fri, 20 Oct 1995 06:57:14 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA03431 for ; Fri, 20 Oct 1995 06:57:11 -0700 Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA23944; Fri, 20 Oct 1995 06:56:31 -0700 Message-ID: <3087AA8F.2781E494@FreeBSD.org> Date: Fri, 20 Oct 1995 06:56:31 -0700 From: "Jordan K. Hubbard" X-Mailer: Mozilla 2.0b1 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: marino.ladavac@aut.alcatel.at CC: John Birrell , hackers@FreeBSD.org Subject: Re: NetBSD/FreeBSD (pthreads) References: <9510201221.AA26512@atuhc16.aut.alcatel.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk marino.ladavac@aut.alcatel.at wrote: > > to be. So we changed libc to allow for threads. We build it twice, once with a > > preprocessor definition _THREAD_SAFE and once without it. For the threaded > > version, a few extra source files are compiled. We always link against libc, > > never libpthread.a and _then_ libc. The MIT implementation tries to sit on top > > of a system like FreeBSD/NetBSD. We believe that it should be part of it. Sorry, I'm coming into this late. This is interesting in that it's almost word-for-word identical to the proposal that was being floated around the table when David and I last talked to Chris Provenzano a USENIX or so back. I find it strange that they would be unreceptive now.. In any case, this was the proposal that I certainly liked best and (I think) David as well. One library without the extra bloat, another compiled to be thread safe. Fine! When can we have the diffs? :-) > > We've ported all our non-threaded code to FreeBSD (2.0.5R). With the exception > > of the function in the kernel which locates SYSVSHM segments, there were no > > problems. (NetBSD fixed SYSVSHM a few months ago. 2.0.5R behaves as NetBSD Could you perhaps elaborate on this a bit? It would certainly be good to fix any brokenness that exists in our SYSVSHM code, if it exists. > > did). We're currently writing widgets so that we don't rely on Motif. Then all > > we need is libc in FreeBSD to be ported to support pthreads and we have our > > factory process monitoring and control product ready to go under FreeBSD. Hmm! I'd be very interested to hear any reports you'd be willing to share about your customers experiences with FreeBSD and your product, when and if you have situations where they're deployed together. It's always good to know how our stuff behaves in the field! :) -- Jordan From owner-freebsd-hackers Fri Oct 20 07:11:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA05153 for hackers-outgoing; Fri, 20 Oct 1995 07:11:57 -0700 Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA05142 for ; Fri, 20 Oct 1995 07:11:49 -0700 Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id GAA17548 for hackers@freebsd.org; Fri, 20 Oct 1995 06:15:19 -0400 From: Peter Dufault Message-Id: <199510201015.GAA17548@hda.com> Subject: DT2801 and DT2811 (data acq) drivers To: hackers@freebsd.org Date: Fri, 20 Oct 1995 06:15:18 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 510 Sender: owner-hackers@freebsd.org Precedence: bulk (The DT2801 and DT2811 are AT bus Data Translation data acq boards) I have a DT2811 driver I'd like to move into -stable, but I no longer have access to a DT2811. If anyone does and will test it please let me know. I'm also writing a DT2801 driver. If anyone wants to test it or send me a list of their requirements please do so. Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-hackers Fri Oct 20 07:29:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA05876 for hackers-outgoing; Fri, 20 Oct 1995 07:29:08 -0700 Received: from sass165.sandia.gov (sass165.sandia.gov [132.175.109.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA05871 for ; Fri, 20 Oct 1995 07:29:05 -0700 Received: from sargon.mdl.sandia.gov (sargon.mdl.sandia.gov [134.253.20.128]) by sass165.sandia.gov (8.6.11/8.6.12) with ESMTP id IAA01798 for ; Fri, 20 Oct 1995 08:32:28 -0600 Received: (aflundi@localhost) by sargon.mdl.sandia.gov (8.6.10) id IAA12025 for freebsd-hackers@freebsd.org; Fri, 20 Oct 1995 08:29:00 -0600 Message-Id: <199510201429.IAA12025@sargon.mdl.sandia.gov> From: aflundi@sandia.gov (Alan F Lundin) Date: Fri, 20 Oct 1995 08:28:59 -0600 In-Reply-To: "Ron G. Minnich" "Re: NetBSD/FreeBSD (pthreads)" (Oct 20, 9:10am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: freebsd-hackers@freebsd.org Subject: Re: NetBSD/FreeBSD (pthreads) Sender: owner-hackers@freebsd.org Precedence: bulk On Oct 20, 9:10am, "Ron G. Minnich" wrote: > Subject: Re: NetBSD/FreeBSD (pthreads) > > I implemented a simple version of plan9 rfork() a little while ago (well, > a year ago). You could rfork and end up with shared data space and file > table. I also implemented a very simple lock/unlock primitive that was > [ ... ] > > For my money this is about as good as kernel threads. There's not the > additional complexity in the kernel (have you ever seen what LWP did to > sunos? No? good.). > > This code has been available gratis for a year. I can't convince anyone > to pull it into core for netbsd or freebsd, but I'll make the offer > again: you want it, let me know. The code, btw, is less than 100 lines > for each change. In fact the fastlock code is something like 25 lines. > I've implemented them as LKMs and directly as part of the kernel. I've been really surprised that there hasn't been a great deal more interest in this (than I've seen anyway). Rob Pike argues pretty well, I think, that kernel threads are a really bad idea, and that the rfork paradigm is more efficient, more powerful, and much simplier to implement (this is that hard to find combination for which I use the adjective "elegant"). His argument goes something like: any time you put threads in the kernel you've fixed the "weight" of the thread, i.e., what is shared between the threads. While with rfork you essentially create "variable weight" threads -- sharing the attributes between processes that are needed for that particular problem. He also noted that adding kernel threads adds a significant "weight" to the process. Larry McVoy has argued that putting "lightweight threads" in the Solaris 2 kernel has made threads about as heavy as normal processes, and Solaris 2 processes now are very heavy, and so is strongly in favor of the rfork concept. There's other evidence that the rfork concept is a good one. After the fact (of making the decision to use rfork in Plan-9 rather than traditional threads), a survey was conducted on the source on the system, and it was found that rfork was almost always called with different attributes being shared, confirming that the flexibility of user defined attribute sharing is used in practice. I haven't thought about it a lot yet, but I'd expect that a user-land library could easily be written using rfork that looks just like pthreads. And I haven't seen or been able to think of any drawbacks or weaknesses to the rfork approach. In any case, I think Ron's rfork implementation for FreeBSD deserves a close and careful look before the kernel gets burdened with a traditional "thread" addition. For those interested in reading more, the Plan-9 overview paper at http://plan9.att.com/plan9/doc/9.html has a section on rfork and its rational. Also there are other documents at ftp://plan9.att.com/plan9/doc/* that probably discuss this more (I'm not sure what's there any more as it has had a fairly major reorganization). --alan From owner-freebsd-hackers Fri Oct 20 08:33:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA07872 for hackers-outgoing; Fri, 20 Oct 1995 08:33:45 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA07867 for ; Fri, 20 Oct 1995 08:33:42 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id LAA01254; Fri, 20 Oct 1995 11:49:01 -0400 Date: Fri, 20 Oct 1995 11:49:01 -0400 Message-Id: <199510201549.LAA01254@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Ade Barkah From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk > >> There is the small issue of what the telco charges . It costs me about >> $100/month to keep my 128kb ISDN Line up for the whole month and that >> includes my ISP v-site.net . If you're ISP gives you 128k of bandwidth for $100. he must be overselling big time. It doesn't matter how you come in...backbone bandwidth is backbone bandwidth. db ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Fri Oct 20 08:38:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA08042 for hackers-outgoing; Fri, 20 Oct 1995 08:38:16 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA08037 for ; Fri, 20 Oct 1995 08:38:11 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id LAA01261; Fri, 20 Oct 1995 11:53:32 -0400 Date: Fri, 20 Oct 1995 11:53:32 -0400 Message-Id: <199510201553.LAA01261@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Terry Lambert From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> > There is the small issue of what the telco charges . It costs me about >> > $100/month to keep my 128kb ISDN Line up for the whole month and that >> > includes my ISP v-site.net . >> > >> > So what do the telcos usually charge for a fraction of a T1? >> >> In the order of $500 depending how far away you are from your isp's >> POP, plus another $1200 to $1600 to pay the provider (we're talking >> 128kbps fractional t1.) Some telcos charge you for a full t1 even >> if you only use a fraction of it. >> >> To bad I can't get ISDN at home for my FreeBSD machine =( =(. >> (complain complain U.S. West) > >You don't want ISDN anyway. In most US West areas (yes, we know you >have it better than the rest of us, Colorado!) they charge message >unit charges over a certain usage limit, with tarrif provisions for >reducing that usage limit to 0 at their option at some future date. > >This is done with the rationale that you are tying up switching >equipment, which you wouldn't be tying up if you were using Frame >Relay (packet switched) instead of ISDN (circuit switched) in the >first place. > >The Telco's are hedging their bets, since they want to be able to >meter your usage in the future (an unrealistic goal for Frame Relay), >and so are really, really pushing ISDN. > The telcos also have a significant advantage with ISDN, because they're the only ones who spent the billions necessary to "tool up". With a private line or frame relay, there is much competition. They'll operate ISDN at a loss for a while, but don't count on it forever. I wouldn't invest too much in ISDN equipment that may get thrown away. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Fri Oct 20 09:08:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA09326 for hackers-outgoing; Fri, 20 Oct 1995 09:08:19 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA09287 ; Fri, 20 Oct 1995 09:08:05 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id MAA01303; Fri, 20 Oct 1995 12:23:37 -0400 Date: Fri, 20 Oct 1995 12:23:37 -0400 Message-Id: <199510201623.MAA01303@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Jordan K. Hubbard" From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk Jordan writes.. >> Actually, Dennis started this thread by trying to get a price reference for >> the Async solution that Jordan referred to....I did not start it by saying >> that sync is better than async. My point was that if for about the same >> money you can have a more flexible solution that will use less of your CPU >> it is worth considering. Unlike most of you, my perspective is > >All true, and now that we've established that the basic cost of entry >(not counting the line itself) for a TA and a serial card is about $650 >(or 2X if you're responsible for both sides), the final question simply >remains as to whether the cost *increment* to get that last 38.9% or so >is worth it. I'm not saying it is or isn't either way, and 38.9% is >certainly nothing to sneeze at (that's basically one V.34 modem's worth >of pipe you're *losing*), but if sync serial cards cost half again what >the TAs cost, well, that's a steep knee in the price/performance curve >too! :( > >That's why I was optimistic about the ISDN card solutions: They're >cheaper than TAs, they give you your full 128K, and when drivers become >available (and they will, I am confident) they are just as plug-n-play >as a TA to anyone reasonably competent with a screwdriver. People are >plugging in their own VGA cards, I suppose they can handle an ISDN card! >:) > >However, you've already said that you don't like the ISDN cards and >consider them too limited, so we're back to the cost argument again. >Maybe what's needed is a low-end sync serial card that doesn't cost much >more than $150 and does everything up to 512K or so on one port. Target >it at the end user who only has (and needs) one connection and might go >frac-T1 someday but will most likely be pottering around at 128Kb for >some time. Let's face it, most of us will never have a T1 at home. We >will dream about it, but that's going to be the premium business pipe >for some time and I don't expect it to fall within the reach of mere >mortals anytime soon! If I'm even going 256K by the end of '96 I'll be >pretty happy. So I would have need for a pair of sync-serial cards that >were cheap and would do everything up to this data rate for at least 2 >years, and that's all the service life I expect from *any* computer >related component these days.. :-) I'm not an ISP, I'm an end-user and >my needs and budget are rather different than the market you probably >deal with ordinarily.. You can sell one for $150. if you want! Find someone who'll take 1,000 at a time and is willing to do the support and pay COD then we can talk. If you want a dumb controller, fine, but that defeats the purpose, and then it won't do frac T1 very well. I'm thinking about a $600. solution in reasonable quantities (about $250. for the TA and $350. for the card and software). Better than ISDN card solutions because of the HDLC processor power and convertable to leased line. There'd have to be a decent market for it though. You can't sell a handful of cards at low profit..... dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Fri Oct 20 09:21:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA09738 for hackers-outgoing; Fri, 20 Oct 1995 09:21:15 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA09730 for ; Fri, 20 Oct 1995 09:21:10 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id MAA01324; Fri, 20 Oct 1995 12:35:17 -0400 Date: Fri, 20 Oct 1995 12:35:17 -0400 Message-Id: <199510201635.MAA01324@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Joe Greco From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> Joe Greco says..... >> >> >Dennis started this thread on the assertion that his sync serial cards can >> >do very high speeds quite easily :-) >> >> Actually, Dennis started this thread by trying to get a price reference for >> the Async solution that Jordan referred to....I did not start it by saying >> that sync is better than async. > >Okay, the former is true, the latter however was not implied. "Dennis >_continued_ this thread on the assertion that his sync serial cards can do >very high speeds quite easily" .... > >> My point was that if for about the same >> money you can have a more flexible solution that will use less of your CPU >> it is worth considering. > >I agree (but fail to see the "for about the same money" portion of this >statement in your product). > >> Unlike most of you, my perspective is >> marketability....not necessarily your (wrong) opinion that async is just as >> good. > >You haven't been reading. I've clearly stated that there is a performance >penalty (processing overhead, which generally falls into the category of >interrupts) associated with async. There are both benefits and >disadvantages. The benefits include the fact that I can go down to Moe's >Computers a few blocks down the road and pick up a 16550 solution, the fact >that "everybody" speaks async RS232, it's quite reasonably priced, and it's >a longtime PC standard. The disadvantages are that at higher data rates it >starts to eat CPU, and it's async. > >> If its not cheaper, which has always been the sole selling point for >> async, then it's a no-brainer. > >Yes, I agree. But the way I count it, it's cheaper by about $370 per side >(or $740 per solution) - assuming your card is $400 and a standard _dual_ >16550 card is $30ish (I do not wish to bicker over numbers however). > You're missing the point....that Jordan paid $650. for a decent async/BONDING TA and sync/BONDING TA's can be gotten for about $260. So the price comparision that we were talking about was $680. ($650. + $30.) per side for async, and $660. ($260. + $400.) for sync. Now these may not be the best numbers available, but the thread is based on those numbers. If all TAs can do sync and async bonding equally well, then you are right. But sync bonding is more efficient and easier to implement, so they're not. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Fri Oct 20 10:46:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA12289 for hackers-outgoing; Fri, 20 Oct 1995 10:46:36 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA12283 for ; Fri, 20 Oct 1995 10:46:34 -0700 Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id KAA09559; Fri, 20 Oct 1995 10:46:14 -0700 Message-ID: <3087E066.A5B0608@FreeBSD.org> Date: Fri, 20 Oct 1995 10:46:14 -0700 From: "Jordan K. Hubbard" X-Mailer: Mozilla 2.0b1 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: dennis CC: hackers@FreeBSD.org Subject: Re: Bragging rights.. References: <199510201623.MAA01303@etinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk dennis wrote: > I'm thinking about a $600. solution in reasonable quantities (about $250. > for the TA and $350. for the card and software). Better than ISDN card I think you're being pretty optimistic about the cost of the TA.. And why so much for the card? You're telling me it costs more to make a sync serial card than a reasonably high quality TA? -- Jordan From owner-freebsd-hackers Fri Oct 20 10:55:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA13066 for hackers-outgoing; Fri, 20 Oct 1995 10:55:18 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA13057 for ; Fri, 20 Oct 1995 10:55:06 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id TAA29165; Fri, 20 Oct 1995 19:54:51 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id TAA02708; Fri, 20 Oct 1995 19:54:50 +0200 Message-Id: <199510201754.TAA02708@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: Bruce Evans cc: hackers@freebsd.org Subject: Re: Creating a /dev/random Date: Fri, 20 Oct 1995 19:54:50 +0200 From: Mark Murray Sender: owner-hackers@freebsd.org Precedence: bulk > >There is a problem with this. The interrupt handler is called with a unit > >number, which is non-unique. There is no way to get back to the original > >interrupt handler. > > >(you suggested:) > >> I think you will need to hook selected interrupt handlers to get dynamic > >> interrupt information. INTR() is too static. The following would almost > >> work: > >> > >> void init_interrupt_randomness(void) { > >> for (each irq of interest) { > >> prev_intr_handler[irq] = intr_handler[irq]; > >> prev_intr_unit[irq] = intr_unit[irq]; > >> disable_intr(); > >> intr_handler[irq] = add_interrupt_randomness; > >> intr_unit[irq] = irq; > ^^^^^^^^^^^^^^^^^^^^ > This replaces the non-unique unit number by the unique irq number. Sure... > >> enable_intr(); > >> } > >> } > >> > >> void add_interrupt_randomness(int irq) { <-- units, not irq's > units, because the many to one > irq -> unit map has been replaced > by irq -> irq. Yes, but the interrupt routine is _called_ with a non-unique unit. There is no way to get to the original interrupt. > >> (*prev_intr_handler[irq])(prev_intr_unit[irq]); <=== won't work > > as units are mostly > > small numbers > works, because of > the remapping I cant see how. The many -> one is OK, the reverse does not work. > >> >+i386/isa/random.c standard > >> > >> Should be optional. Perhaps `optional random device-driver'. > > >I would rather make it a permanent fixture. When random.c is compiled > >the object file is about 5k, not much for the bloatists to complain > >about ;-). If software developers like Netscrape could count on > >this device being present, then they would use it. If it is optional, > >it may as well be not there. These are Ts'o's sentiments as well. > >Right now there are #ifdef DEVRANDOM constructs around the code, > >which I would like to remove when it is stable. > > I guess the device interface has to be standard and the randomness > calculations, especially the ones that waste time as well as space, > optional. Developers won't like having different interfaces for > Linux, FreeBSD, BSDI, ... Well - this is an attemt to set trends. :-) It is proposed code from the Linux camp - and if it is popular enough, everyone will use it. One way to help this is to make it always present, and then to advertise its presence. BTW - this has an identical user interface to Linux, and is easily transportable to other platforms. I have looked on our Suns at work :-) :-) :-) > >> Does it really have isa dependencies? The other isa includes in machdep.c > >> are bogus too. > > >is this the wrong place to put this header? It is a short file containing > >necessary function prototypes. > > I'm not sure. Does it break on pci systems? If not, then it probably > doesn't belong in /sys/i386/isa. It may even belong in /sys/sys. Don't > worry about this much. The mem driver has many similarly misplaced > things. It's hard to imagine a machine-dependent implementation of > /dev/null, and the implementation of /dev/zero is machine-independent, > and the implementation of /dev/mem is almost machine independent, yet > these devices are mixed with the very machine-dependent /dev/io. I believe it will work on PCI and EISA systems, bit I don't know for sure. I'm mostly easy about wheere this lives. I'm not crazy about sys/sys. There is nothing in ths header that is anyone's business outside the kernel. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-hackers Fri Oct 20 11:19:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA14898 for hackers-outgoing; Fri, 20 Oct 1995 11:19:44 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA14893 ; Fri, 20 Oct 1995 11:19:41 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA29469; Fri, 20 Oct 1995 13:18:49 -0500 From: Joe Greco Message-Id: <199510201818.NAA29469@brasil.moneng.mei.com> Subject: Re: Bragging rights.. To: jkh@freebsd.org (Jordan K. Hubbard) Date: Fri, 20 Oct 1995 13:18:49 -0500 (CDT) Cc: dennis@etinc.com, hackers@freebsd.org In-Reply-To: <3087E066.A5B0608@FreeBSD.org> from "Jordan K. Hubbard" at Oct 20, 95 10:46:14 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > dennis wrote: > > > I'm thinking about a $600. solution in reasonable quantities (about $250. > > for the TA and $350. for the card and software). Better than ISDN card > > I think you're being pretty optimistic about the cost of the TA.. And > why so much for the card? You're telling me it costs more to make a > sync serial card than a reasonably high quality TA? Quite possibly :-) I do not find it hard to believe that it costs a lot to produce a "niche" product. Dennis is, however, comparing apples and pumpkins, because he is quoting $250 on one hand for a sync TA, and $650 (the price you paid) for an async TA, when the truth is more like $260 for an inexpensive async TA such as the Bitsurfer. Given a sufficiently inexpensive sync serial card, physical control of both ends of the link (so that you don't have somebody charging you a fortune for the privilege of doing sync serial on a router port, etc), I think it could be a really good solution. I would do it myself. :-) However, I do not see it as being practical for a large number of people. For the reasons previously stated. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Fri Oct 20 11:22:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA15013 for hackers-outgoing; Fri, 20 Oct 1995 11:22:58 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA15004 ; Fri, 20 Oct 1995 11:22:53 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id OAA01640; Fri, 20 Oct 1995 14:38:29 -0400 Date: Fri, 20 Oct 1995 14:38:29 -0400 Message-Id: <199510201838.OAA01640@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Jordan K. Hubbard" From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >dennis wrote: > >> I'm thinking about a $600. solution in reasonable quantities (about $250. >> for the TA and $350. for the card and software). Better than ISDN card > >I think you're being pretty optimistic about the cost of the TA.. Motorola T/As can be gotten for that number now. > And >why so much for the card? You're telling me it costs more to make a >sync serial card than a reasonably high quality TA? I think that Motorola sells a few more T/As than I sell cards. Plus you need some room for resellers. These unix guys buy 1 at a time and want quantity 100 prices, and then I have to set it up for them because they don't have a tiny clue on how to do anything. If you call me up and I'm only making $100. on you, I don't have time to talk to you. You call Motorola and you get some $12. an hour techie, you call ET and you get the guy that wrote the software. It doesn't sound that exciting, but supporting FreeBSD has a tremendous overhead considering that the potential market is tiny (compared to Windows, for example). The big guys can't even recover development costs on BSD type Unixes, which is why they won't touch it. I've recently lowered my prices, and I'm selling a lot more product at a lower profit. I may lose on the deal..as its a major pain in the butt to fill the orders and handle the extra customer support. I certainly don't want 1000 guys buying cheap cards and calling me up or sending them back because they can't make them work. Maybe I can call forward my tech support line to your house and we can do a deal? Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Fri Oct 20 11:48:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA15716 for hackers-outgoing; Fri, 20 Oct 1995 11:48:01 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA15711 for ; Fri, 20 Oct 1995 11:47:56 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id PAA01704; Fri, 20 Oct 1995 15:01:57 -0400 Date: Fri, 20 Oct 1995 15:01:57 -0400 Message-Id: <199510201901.PAA01704@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Joe Greco From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> dennis wrote: >> >> > I'm thinking about a $600. solution in reasonable quantities (about $250. >> > for the TA and $350. for the card and software). Better than ISDN card >> >> I think you're being pretty optimistic about the cost of the TA.. And >> why so much for the card? You're telling me it costs more to make a >> sync serial card than a reasonably high quality TA? > >Quite possibly :-) I do not find it hard to believe that it costs a lot to >produce a "niche" product. > >Dennis is, however, comparing apples and pumpkins, because he is quoting >$250 on one hand for a sync TA, and $650 (the price you paid) for an async >TA, when the truth is more like $260 for an inexpensive async TA such as the >Bitsurfer. I'm just going by what Jordan said.......... > >Given a sufficiently inexpensive sync serial card, physical control of both >ends of the link (so that you don't have somebody charging you a fortune for >the privilege of doing sync serial on a router port, etc), I think it could >be a really good solution. I would do it myself. :-) > If you can get an extras $50 or $100 a month the price of the card is recovered quite quickly. and since the smart sync uses less CPU at the hub, you get more use out of your hub CPU. Its a selling point, for those that want it. If you have an advantage over other ISPs then you can lure more customers. Its just business. Not for everyone, of course. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Fri Oct 20 11:59:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA15924 for hackers-outgoing; Fri, 20 Oct 1995 11:59:29 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id LAA15919 for ; Fri, 20 Oct 1995 11:59:27 -0700 Received: from gemini.sdsp.mc.xerox.com ([13.231.132.20]) by alpha.xerox.com with SMTP id <15464(3)>; Fri, 20 Oct 1995 11:55:08 PDT Received: from gnu.mc.xerox.com (gnu.sdsp.mc.xerox.com) by gemini.sdsp.mc.xerox.com (4.1/SMI-4.1) id AA06398; Fri, 20 Oct 95 14:55:07 EDT Received: by gnu.mc.xerox.com (4.1/SMI-4.1) id AA17636; Fri, 20 Oct 95 14:55:06 EDT Message-Id: <9510201855.AA17636@gnu.mc.xerox.com> X-Mailer: exmh version 1.6.4 10/10/95 To: John Birrell Cc: mira!sdsp.mc.xerox.com!leisner@werple.net.au (Marty Leisner), hackers@freebsd.org, jb@cimlogic.com.au Subject: Re: NetBSD/FreeBSD (pthreads) In-Reply-To: Your message of "Thu, 19 Oct 1995 15:25:25 PDT." <199510192222.IAA02052@werple.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Oct 1995 11:55:04 PDT From: "Marty Leisner" Sender: owner-hackers@freebsd.org Precedence: bulk Why would I want kernel level threads? 1) does a debugger understand userlevel threads? 2) if I run a threaded application under strace, with kernel levels threads is may make some sense...with user level threads there's all this junk in the way... 3) Anyone have good hard numbers about the differences between user/kernel level threads on performance? Like I said, the mit package is awfully clever... -- marty leisner@sdsp.mc.xerox.com Member of the League for Programming Freedom From owner-freebsd-hackers Fri Oct 20 12:05:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA16115 for hackers-outgoing; Fri, 20 Oct 1995 12:05:47 -0700 Received: from salmon.maths.tcd.ie (mmdf@salmon.maths.tcd.ie [134.226.81.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA15981 ; Fri, 20 Oct 1995 12:00:41 -0700 Received: from gosset.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id aa18911; 20 Oct 95 18:10 BST To: thomas@lkg.dec.com Subject: de0 support for SMC8432BT EtherPower PCI Cc: questions@freebsd.org, nops@maths.tcd.ie, hackers@freebsd.org Date: Fri, 20 Oct 1995 18:10:39 +0100 From: Alan Judge Message-ID: <9510201810.aa18911@salmon.maths.tcd.ie> Sender: owner-hackers@freebsd.org Precedence: bulk We've just got a new server with one of these cards installed. We installed 2.1.0-951005-SNAP via ftp using the card and all worked fine. However, when the new system rebooted, it said that the ethernet address was unknown. Further probing and debugging reveals that the card seems to contain a DC21041 chip rather than a 21040. The initial unknown problem was due to yet another PROM layout (ether address at offset 20, but only 32 bytes altogether). I fixed this and got a little further but am now getting trap faults. Before going any further (and while I compile a debugging kernel), I want to check if anyone else has one of these new SMC cards or has solved the 21041 support issue. A hint as to why the boot floppy works might help a lot. -- Alan From owner-freebsd-hackers Fri Oct 20 12:22:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA16370 for hackers-outgoing; Fri, 20 Oct 1995 12:22:32 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA16364 for ; Fri, 20 Oct 1995 12:22:30 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id MAA00242; Fri, 20 Oct 1995 12:22:12 -0700 From: Julian Elischer Message-Id: <199510201922.MAA00242@ref.tfs.com> Subject: Re: NetBSD/FreeBSD (pthreads) To: rminnich@Sarnoff.COM (Ron G. Minnich) Date: Fri, 20 Oct 1995 12:22:12 -0700 (PDT) Cc: cimaxp1!jb@werple.net.au, mira!sdsp.mc.xerox.com!leisner@werple.net.au, hackers@freebsd.org, jb@cimlogic.com.au In-Reply-To: from "Ron G. Minnich" at Oct 20, 95 09:10:43 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2814 Sender: owner-hackers@freebsd.org Precedence: bulk Actually I believe I still have the code 'pack-rat'ed away somewhere.. I'd like to be able to add it to the FreeBSD kernel, and I'm not alone, but it's such a deep-seated set of changes that I think it deserves more of a analysis than I have been able to give it. When Davidg comes out of 2.1 coma, and maybe john dyson is available I'd like to go over this stuff for a couple of itterations to get it to the stage that everyone is happy with it and put it into the kernel.. certainly a 'threads' implimentation based on rfork is a very tempting way to go. have you kept your code -up-to-date? when I saw it last, it was a NETBSD implimentation and I didn't have the time top port it.... there are a couple of things I'd like to see before I pulled it into -current: 1/ Able to be COMPLETELY left out if so desired.. i.e. not configuring it in should leave every thing EXACTLY as it is now 2/ supplied as a set of patches to -current 3/ agreement from davind and john 4/ documantation and possibly references to the original idea (plan9?) For the record, Kirk said at the 4.4 course I did a while ago that he thought that rfork was a good alternative to kernel threads.. do you have a pointer to your present code? > > I implemented a simple version of plan9 rfork() a little while ago (well, > a year ago). You could rfork and end up with shared data space and file > table. I also implemented a very simple lock/unlock primitive that was > far more efficient than system v semaphores, since in the common case > (no contention for a lock) there's no jump to the kernel to wake up > other procs when you acquire or free a lock. Between these two things you > can do a lot: share data, share locked structures, share open files, etc. > I can do all of what i commonly do with kernel threads on, e.g., Irix. In > fact I implemented a simple user-space distributed shared memory with > these basic parts: on sgi's i used their kernel threads/kernel mutex > code, on freebsd i used rfork/lock code i built. > > For my money this is about as good as kernel threads. There's not the > additional complexity in the kernel (have you ever seen what LWP did to > sunos? No? good.). > > This code has been available gratis for a year. I can't convince anyone > to pull it into core for netbsd or freebsd, but I'll make the offer > again: you want it, let me know. The code, btw, is less than 100 lines > for each change. In fact the fastlock code is something like 25 lines. > I've implemented them as LKMs and directly as part of the kernel. > > ron > > Ron Minnich |Like a knife through Daddy's heart: > rminnich@earth.sarnoff.com |"Don't make fun of Windows, daddy! It takes care > (609)-734-3120 | of all my files and it's reliable and I like it". > > > From owner-freebsd-hackers Fri Oct 20 12:44:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA16837 for hackers-outgoing; Fri, 20 Oct 1995 12:44:19 -0700 Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA16832 for ; Fri, 20 Oct 1995 12:44:16 -0700 Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id PAA03032; Fri, 20 Oct 1995 15:41:09 -0400 Date: Fri, 20 Oct 1995 15:41:09 -0400 (EDT) From: "Ron G. Minnich" To: Julian Elischer cc: cimaxp1!jb@werple.net.au, mira!sdsp.mc.xerox.com!leisner@werple.net.au, hackers@freebsd.org, jb@cimlogic.com.au Subject: Re: NetBSD/FreeBSD (pthreads) In-Reply-To: <199510201922.MAA00242@ref.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk the code is up-to-date. It runs on 2.0R, but i think will work on 2.05R with zero change. John Dyson and jordan now have copies. I'm amenable to options RFORK in the config file :-) It really is a very simple set of changes, so i hope we can do this. I'm willing to change what needs changing. I would love to have this go in, i've found it useful. Thanks! Ron Minnich |Like a knife through Daddy's heart: rminnich@earth.sarnoff.com |"Don't make fun of Windows, daddy! It takes care (609)-734-3120 | of all my files and it's reliable and I like it". From owner-freebsd-hackers Fri Oct 20 13:02:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA17236 for hackers-outgoing; Fri, 20 Oct 1995 13:02:50 -0700 Received: from keystone.cmp.com (keystone.cmp.com [198.80.26.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA17228 for ; Fri, 20 Oct 1995 13:02:44 -0700 Received: from smtpgate.cmp.com ([198.80.26.6]) by keystone.cmp.com with ESMTP (1.37.109.14/17.1) id AA254779187; Fri, 20 Oct 1995 15:59:47 -0400 Received: from Microsoft Mail (PU Serial #1151) by smtpgate.cmp.com (PostalUnion/SMTP(tm) v2.1.8d for Windows NT(tm)) id AA-1995Oct20.160329.1151.328121; Fri, 20 Oct 1995 16:03:45 -0400 From: cstealey@cmp.com (Stealey Christopher) To: hackers@freebsd.org ('hackers@freebsd.org') Message-Id: <1995Oct20.160329.1151.328121@smtpgate.cmp.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: CMP Publications, Inc. Date: Fri, 20 Oct 1995 16:03:45 -0400 Subject: Xircom Sender: owner-hackers@freebsd.org Precedence: bulk Has anyone ever written drivers for FreeBSD(good or quirky) to support the Xircom pocket Ethernet Adapter (specifically pe2 and pe3) ? I know that bsdi includes support for these adapters, So I figure its possible someone could have figured out the code, etc. Any info you can give me on this would be greatly appreciated. Christopher Stealey Systems Coordinator CMP Publications, Inc. From owner-freebsd-hackers Fri Oct 20 13:28:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA18178 for hackers-outgoing; Fri, 20 Oct 1995 13:28:18 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA18162 for ; Fri, 20 Oct 1995 13:28:10 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA05241; Fri, 20 Oct 1995 13:20:59 -0700 From: Terry Lambert Message-Id: <199510202020.NAA05241@phaeton.artisoft.com> Subject: Re: Duplicating whole disks To: freebsd@fgate.flevel.co.uk (freebsd) Date: Fri, 20 Oct 1995 13:20:59 -0700 (MST) Cc: hackers@FreeBSD.ORG, graham@flevel.co.uk In-Reply-To: from "freebsd" at Oct 20, 95 10:10:19 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 980 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > From time to time we need to make exact copies of a large number of hard > drives partitioned with freebsd. > > The drives are external SCSIs. > > Opinions please on the most efficient and fastest method. > > Would you please Cc: graham@flevel.co.uk Make an image of an unmounted disk on a larger disk. Copy the images verbatim to the smaller disks. Be sure you turn on media perfection to avoid sector relocation difference on a drive-by-drive basis. The easiest way to establish this setup is to install FreeBSD onto a smaller disk with whatever else you want installed to create the initial image, then change the SCSI ID and read the image onto the mastering disk. Then write the image to each new disk. Using vnconfig, you should be able to actually mount, modify, and unmount the image as well to make incremental changes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Oct 20 13:36:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA18575 for hackers-outgoing; Fri, 20 Oct 1995 13:36:39 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA18568 for ; Fri, 20 Oct 1995 13:36:32 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA05261; Fri, 20 Oct 1995 13:28:10 -0700 From: Terry Lambert Message-Id: <199510202028.NAA05261@phaeton.artisoft.com> Subject: Re: NetBSD/FreeBSD (pthreads) To: leisner@sdsp.mc.xerox.com (Marty Leisner) Date: Fri, 20 Oct 1995 13:28:10 -0700 (MST) Cc: cimaxp1!jb@werple.net.au, leisner@sdsp.mc.xerox.com, hackers@FreeBSD.ORG, jb@cimlogic.com.au In-Reply-To: <9510201855.AA17636@gnu.mc.xerox.com> from "Marty Leisner" at Oct 20, 95 11:55:04 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1038 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Why would I want kernel level threads? > > 1) does a debugger understand userlevel threads? > 2) if I run a threaded application under strace, with kernel > levels threads is may make some sense...with user level threads > there's all this junk in the way... > 3) Anyone have good hard numbers about the differences between user/kernel > level threads on performance? Yeah. On an 8 processor box, a kernel-threaded app is 8 times as concurrent as a user threaded app (which by definition can only utilize one processor at a time). Consider also that thengs like statfs/fstatfs are potentially long-blocking operations that aren't select()'able. Debugging tools are another (almost completely unrelated) problem. > Like I said, the mit package is awfully clever... So's the AT&T/Sun stuff. The problem is that no one has bothered with implementing both types of clever in the same package. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Oct 20 13:38:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA18649 for hackers-outgoing; Fri, 20 Oct 1995 13:38:18 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA18631 ; Fri, 20 Oct 1995 13:38:06 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id NAA00872; Fri, 20 Oct 1995 13:37:54 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id NAA01153; Fri, 20 Oct 1995 13:35:45 -0700 Message-Id: <199510202035.NAA01153@corbin.Root.COM> To: Alan Judge cc: thomas@lkg.dec.com, questions@freebsd.org, nops@maths.tcd.ie, hackers@freebsd.org Subject: Re: de0 support for SMC8432BT EtherPower PCI In-reply-to: Your message of "Fri, 20 Oct 95 18:10:39 BST." <9510201810.aa18911@salmon.maths.tcd.ie> From: David Greenman Reply-To: davidg@Root.COM Date: Fri, 20 Oct 1995 13:35:43 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >We've just got a new server with one of these cards installed. We >installed 2.1.0-951005-SNAP via ftp using the card and all worked >fine. > >However, when the new system rebooted, it said that the ethernet >address was unknown. Further probing and debugging reveals that the >card seems to contain a DC21041 chip rather than a 21040. The initial >unknown problem was due to yet another PROM layout (ether address at >offset 20, but only 32 bytes altogether). I fixed this and got a >little further but am now getting trap faults. > >Before going any further (and while I compile a debugging kernel), I >want to check if anyone else has one of these new SMC cards or has >solved the 21041 support issue. A hint as to why the boot floppy >works might help a lot. Hmmm...the driver in the 10-5 snapshot has Matt's fixes for the 21041...and since it works on the install floppy, this is really strange. What revision is the if_de.c file in your sources? Look for $Id: just after the copyright. -DG From owner-freebsd-hackers Fri Oct 20 13:50:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA19106 for hackers-outgoing; Fri, 20 Oct 1995 13:50:41 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA19099 for ; Fri, 20 Oct 1995 13:50:32 -0700 Received: from exalt.x.org by expo.x.org id AA14804; Fri, 20 Oct 95 16:49:58 -0400 Received: from localhost by exalt.x.org id QAA05443; Fri, 20 Oct 1995 16:49:56 -0400 Message-Id: <199510202049.QAA05443@exalt.x.org> To: hackers@freefall.FreeBSD.org Subject: Netscape puzzle Date: Fri, 20 Oct 1995 16:49:55 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk Here's something weird. I'm not looking for an answer or a fix. I'm merely telling you about this so that when someone else says it happened to them you can say you've heard of it happening before. My box at home is running FreeBSD 2.1.0-950922-SNAP, connected to the network at work by PPP through ZOOM V.34 28.8K modems and a Cisco terminal server. It's not unusual for my PPP link to stay up for days at a time normally. >From work, if I rsh to my box and run netscape 2.0b1 with the display set to a machine here at work, I get an "unable to open display" error. With netscape 1.1 it runs for several seconds and then takes the PPP connection down. This has occured each and every time I've tried it. Other X programs connect to displays at work and run fine. Both versions of netscape run fine when connected to the local X server by Unix domain socket. I think netscapes running the other direction, i.e. from work to my box also work fine, I'll have to try again when I get home to be sure. -- Kaleb KEITHLEY From owner-freebsd-hackers Fri Oct 20 13:59:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA19334 for hackers-outgoing; Fri, 20 Oct 1995 13:59:21 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA19301 ; Fri, 20 Oct 1995 13:59:02 -0700 Received: from salmon.maths.tcd.ie (mmdf@salmon.maths.tcd.ie [134.226.81.11]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id NAA14257 ; Fri, 20 Oct 1995 13:54:45 -0700 Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id aa23659; 20 Oct 95 21:49 BST To: davidg@root.com cc: thomas@lkg.dec.com, questions@freebsd.org, nops@maths.tcd.ie, hackers@freebsd.org Subject: Re: de0 support for SMC8432BT EtherPower PCI In-reply-to: Your message of "Fri, 20 Oct 1995 13:35:43 PDT." <199510202035.NAA01153@corbin.Root.COM> Date: Fri, 20 Oct 1995 21:49:08 +0200 From: David Malone Message-ID: <9510202149.aa23659@salmon.maths.tcd.ie> Sender: owner-hackers@freebsd.org Precedence: bulk > >Before going any further (and while I compile a debugging kernel), I > >want to check if anyone else has one of these new SMC cards or has > >solved the 21041 support issue. A hint as to why the boot floppy > >works might help a lot. > > Hmmm...the driver in the 10-5 snapshot has Matt's fixes for the 21041...and > since it works on the install floppy, this is really strange. What revision is > the if_de.c file in your sources? Look for $Id: just after the copyright. The version is 1.29.2.1 - I also note the source for the atapi support is missing, though there are references in the config files. David. From owner-freebsd-hackers Fri Oct 20 14:17:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA19816 for hackers-outgoing; Fri, 20 Oct 1995 14:17:24 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA19808 for ; Fri, 20 Oct 1995 14:17:16 -0700 Received: from gemini.sdsp.mc.xerox.com ([13.231.132.20]) by alpha.xerox.com with SMTP id <17219(5)>; Fri, 20 Oct 1995 14:15:17 PDT Received: from gnu.mc.xerox.com (gnu.sdsp.mc.xerox.com) by gemini.sdsp.mc.xerox.com (4.1/SMI-4.1) id AA08145; Fri, 20 Oct 95 17:15:17 EDT Received: by gnu.mc.xerox.com (4.1/SMI-4.1) id AA19961; Fri, 20 Oct 95 17:15:15 EDT Message-Id: <9510202115.AA19961@gnu.mc.xerox.com> X-Mailer: exmh version 1.6.4 10/10/95 To: Terry Lambert Cc: cimaxp1!jb@werple.net.au, hackers@freebsd.org, jb@cimlogic.com.au Subject: Re: NetBSD/FreeBSD (pthreads) In-Reply-To: Your message of "Fri, 20 Oct 1995 13:28:10 PDT." <199510202028.NAA05261@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Oct 1995 14:15:13 PDT From: "Marty Leisner" Sender: owner-hackers@freebsd.org Precedence: bulk > > Why would I want kernel level threads? > Yeah. On an 8 processor box, a kernel-threaded app is 8 times as > concurrent as a user threaded app (which by definition can only > utilize one processor at a time). > > Threads on multiprocessor boxes can take advantage of concurrency... I missed that... I personally would prefer good ways of solving problems without threads...to throw threads at problems make debugging and understanding much, much harder... Many look at threads as a "kitchen sink coding approach" -- lets use everything we got... Threads are natural for stuff like nfsd where several daemons are forked off... -- marty leisner@sdsp.mc.xerox.com Member of the League for Programming Freedom From owner-freebsd-hackers Fri Oct 20 14:20:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA19957 for hackers-outgoing; Fri, 20 Oct 1995 14:20:30 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA19949 for ; Fri, 20 Oct 1995 14:20:16 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id PAA15970; Fri, 20 Oct 1995 15:22:17 -0600 Date: Fri, 20 Oct 1995 15:22:17 -0600 From: Nate Williams Message-Id: <199510202122.PAA15970@rocky.sri.MT.net> To: "Kaleb S. KEITHLEY" Cc: hackers@freefall.freebsd.org Subject: Re: Netscape puzzle In-Reply-To: <199510202049.QAA05443@exalt.x.org> References: <199510202049.QAA05443@exalt.x.org> Sender: owner-hackers@FreeBSD.org Precedence: bulk > Here's something weird. I'm not looking for an answer or a fix. I'll give you one anyway. > >From work, if I rsh to my box and run netscape 2.0b1 with the display set > to a machine here at work, I get an "unable to open display" error. With > netscape 1.1 it runs for several seconds and then takes the PPP connection > down. This has occured each and every time I've tried it. Why it's taking your connection out, I don't know but I've found that the Netscape versions >= 1.1 I've run on both SunOS and FreeBSD require me using the IP address instead of the hostname if I want to use remote hosts. The Slowlaris versions doesn't for some reason, but I found it interesting none the less. Nate From owner-freebsd-hackers Fri Oct 20 14:22:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA20061 for hackers-outgoing; Fri, 20 Oct 1995 14:22:45 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA20035 ; Fri, 20 Oct 1995 14:22:30 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id OAA00950; Fri, 20 Oct 1995 14:22:28 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id OAA00131; Fri, 20 Oct 1995 14:22:27 -0700 Message-Id: <199510202122.OAA00131@corbin.Root.COM> To: David Malone cc: thomas@lkg.dec.com, questions@freebsd.org, nops@maths.tcd.ie, hackers@freebsd.org Subject: Re: de0 support for SMC8432BT EtherPower PCI In-reply-to: Your message of "Fri, 20 Oct 95 21:49:08 +0200." <9510202149.aa23659@salmon.maths.tcd.ie> From: David Greenman Reply-To: davidg@Root.COM Date: Fri, 20 Oct 1995 14:22:09 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >> >Before going any further (and while I compile a debugging kernel), I >> >want to check if anyone else has one of these new SMC cards or has >> >solved the 21041 support issue. A hint as to why the boot floppy >> >works might help a lot. >> >> Hmmm...the driver in the 10-5 snapshot has Matt's fixes for the 21041...and >> since it works on the install floppy, this is really strange. What revision is >> the if_de.c file in your sources? Look for $Id: just after the copyright. > >The version is 1.29.2.1 - I also note the source for the atapi support >is missing, though there are references in the config files. Uhhh...that should be rev 1.29.2.2 if you have the 951005 snapshot. Perhaps I misread your mail - which snapshot are you using?? -DG From owner-freebsd-hackers Fri Oct 20 14:33:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA20491 for hackers-outgoing; Fri, 20 Oct 1995 14:33:47 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA20484 for ; Fri, 20 Oct 1995 14:33:41 -0700 Received: from exalt.x.org by expo.x.org id AA15999; Fri, 20 Oct 95 17:33:08 -0400 Received: from localhost by exalt.x.org id RAA05549; Fri, 20 Oct 1995 17:33:06 -0400 Message-Id: <199510202133.RAA05549@exalt.x.org> To: Nate Williams Cc: hackers@freefall.FreeBSD.org Subject: Re: Netscape puzzle In-Reply-To: Your message of Fri, 20 Oct 1995 15:22:17 EST. <199510202122.PAA15970@rocky.sri.MT.net> Organization: X Consortium Date: Fri, 20 Oct 1995 17:33:05 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > > Here's something weird. I'm not looking for an answer or a fix. > > I'll give you one anyway. > > > >From work, if I rsh to my box and run netscape 2.0b1 with the display set > > to a machine here at work, I get an "unable to open display" error. With > > netscape 1.1 it runs for several seconds and then takes the PPP connection > > down. This has occured each and every time I've tried it. > > Why it's taking your connection out, I don't know but I've found that > the Netscape versions >= 1.1 I've run on both SunOS and FreeBSD require > me using the IP address instead of the hostname if I want to use remote > hosts. I had tried that and it didn't make any difference with the BSD 2.0b1, I still got an "unable to open display" error. :-( -- Kaleb KEITHLEY From owner-freebsd-hackers Fri Oct 20 14:47:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA21105 for hackers-outgoing; Fri, 20 Oct 1995 14:47:57 -0700 Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA21084 ; Fri, 20 Oct 1995 14:47:51 -0700 Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with SMTP id OAA15375; Fri, 20 Oct 1995 14:46:31 -0700 Received: from bell.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id aa24239; 20 Oct 95 22:38 BST To: davidg@root.com cc: thomas@lkg.dec.com, questions@freebsd.org, nops@maths.tcd.ie, hackers@freebsd.org Subject: Re: de0 support for SMC8432BT EtherPower PCI In-reply-to: Your message of "Fri, 20 Oct 1995 14:24:00 PDT." <199510202124.OAA00146@corbin.Root.COM> Date: Fri, 20 Oct 1995 22:38:45 +0100 From: David Malone Message-ID: <9510202238.aa24239@salmon.maths.tcd.ie> Sender: owner-hackers@freebsd.org Precedence: bulk > >The version is 1.29.2.1 - I also note the source for the atapi support > >is missing, though there are references in the config files. > > A correction on my last email: the 951005 snapshot should have rev 1.29.2.3 I suspect the wrong source has ended up on atleast the server we installed from. I got the 2.1.0-951005-SNAP install disk from ftp://ftp.ieunet.ie/FreeBSD/2.1.0-951005-SNAP. The options menu on this disk says it is the 951005 release. I installed from ftp://ftp.ieunet.ie/FreeBSD/ and the generic kernel I ended up with was 950928, and looking at the rcs info you sent me this is before the changes were made. I wonder if this is a global or local problem. It would certainly explain the missing atapi support too. David. From owner-freebsd-hackers Fri Oct 20 15:19:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA22701 for hackers-outgoing; Fri, 20 Oct 1995 15:19:41 -0700 Received: from salmon.maths.tcd.ie (mmdf@salmon.maths.tcd.ie [134.226.81.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA22509 ; Fri, 20 Oct 1995 15:16:06 -0700 Received: from bell.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id aa24740; 20 Oct 95 23:15 BST To: davidg@root.com cc: thomas@lkg.dec.com, questions@freebsd.org, nops@maths.tcd.ie, hackers@freebsd.org Subject: Re: de0 support for SMC8432BT EtherPower PCI In-reply-to: Your message of "Fri, 20 Oct 1995 14:24:00 PDT." <199510202124.OAA00146@corbin.Root.COM> Date: Fri, 20 Oct 1995 23:15:33 +0100 From: David Malone Message-ID: <9510202315.aa24740@salmon.maths.tcd.ie> Sender: owner-hackers@freebsd.org Precedence: bulk > >The version is 1.29.2.1 - I also note the source for the atapi support > >is missing, though there are references in the config files. > > A correction on my last email: the 951005 snapshot should have rev 1.29.2.3 Futher to my previous note - I've just grabbed ftp://wcarchive.cdrom.com/.3/FreeBSD/2.1.0-951005-SNAP/src/ssys.* and the version number in if_de.c is 1.29.2.1, I guess there must be some weird distribution problem... David. From owner-freebsd-hackers Fri Oct 20 15:27:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA22984 for hackers-outgoing; Fri, 20 Oct 1995 15:27:28 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA22975 for ; Fri, 20 Oct 1995 15:27:17 -0700 Received: by sequent.kiae.su id AA03215 (5.65.kiae-2 ); Sat, 21 Oct 1995 02:27:01 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Sat, 21 Oct 95 02:27:00 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id BAA02131; Sat, 21 Oct 1995 01:25:26 +0300 To: hackers@freefall.FreeBSD.org, "Kaleb S. KEITHLEY" References: <199510202049.QAA05443@exalt.x.org> In-Reply-To: <199510202049.QAA05443@exalt.x.org>; from "Kaleb S. KEITHLEY" at Fri, 20 Oct 1995 16:49:55 EST Message-Id: Organization: Olahm Ha-Yetzirah Date: Sat, 21 Oct 1995 01:25:26 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: Netscape puzzle Lines: 25 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1196 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510202049.QAA05443@exalt.x.org> Kaleb S. KEITHLEY writes: >>From work, if I rsh to my box and run netscape 2.0b1 with the display set >to a machine here at work, I get an "unable to open display" error. With >netscape 1.1 it runs for several seconds and then takes the PPP connection >down. This has occured each and every time I've tried it. >Other X programs connect to displays at work and run fine. Both versions >of netscape run fine when connected to the local X server by Unix domain >socket. I think netscapes running the other direction, i.e. from work to >my box also work fine, I'll have to try again when I get home to be >sure. It seems that some strange bug buried into Netscape2. I can't run it remotely in the same situation. Changing DNS name to IP address not helps in my case, but some others says that it helps. Problem already reported to Netscape team. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Fri Oct 20 15:33:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA23338 for hackers-outgoing; Fri, 20 Oct 1995 15:33:05 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA23319 ; Fri, 20 Oct 1995 15:32:55 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id PAA00267; Fri, 20 Oct 1995 15:32:52 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id PAA00241; Fri, 20 Oct 1995 15:32:43 -0700 Message-Id: <199510202232.PAA00241@corbin.Root.COM> To: David Malone cc: thomas@lkg.dec.com, questions@freebsd.org, nops@maths.tcd.ie, hackers@freebsd.org Subject: Re: de0 support for SMC8432BT EtherPower PCI In-reply-to: Your message of "Fri, 20 Oct 95 23:15:33 BST." <9510202315.aa24740@salmon.maths.tcd.ie> From: David Greenman Reply-To: davidg@Root.COM Date: Fri, 20 Oct 1995 15:32:37 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >> >The version is 1.29.2.1 - I also note the source for the atapi support >> >is missing, though there are references in the config files. >> >> A correction on my last email: the 951005 snapshot should have rev 1.29.2.3 > >Futher to my previous note - I've just grabbed >ftp://wcarchive.cdrom.com/.3/FreeBSD/2.1.0-951005-SNAP/src/ssys.* >and the version number in if_de.c is 1.29.2.1, I guess there must be >some weird distribution problem... Okay, it looks like the last snapshot was screwed up. Jordan is building another one right now... -DG From owner-freebsd-hackers Fri Oct 20 15:43:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA23756 for hackers-outgoing; Fri, 20 Oct 1995 15:43:59 -0700 Received: from salmon.maths.tcd.ie (mmdf@salmon.maths.tcd.ie [134.226.81.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA23688 ; Fri, 20 Oct 1995 15:41:04 -0700 Received: from bell.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id aa25068; 20 Oct 95 23:39 BST To: davidg@root.com cc: thomas@lkg.dec.com, questions@freebsd.org, nops@maths.tcd.ie, hackers@freebsd.org Subject: Re: de0 support for SMC8432BT EtherPower PCI In-reply-to: Your message of "Fri, 20 Oct 1995 15:32:37 PDT." <199510202232.PAA00241@corbin.Root.COM> Date: Fri, 20 Oct 1995 23:39:41 +0100 From: David Malone Message-ID: <9510202339.aa25068@salmon.maths.tcd.ie> Sender: owner-hackers@freebsd.org Precedence: bulk > >Futher to my previous note - I've just grabbed > >ftp://wcarchive.cdrom.com/.3/FreeBSD/2.1.0-951005-SNAP/src/ssys.* > >and the version number in if_de.c is 1.29.2.1, I guess there must be > >some weird distribution problem... > Okay, it looks like the last snapshot was screwed up. Jordan is building > another one right now... Many thanks, I'm sure you don't need stuff like this before you go home on a Friday. Have a good weekend. David. From owner-freebsd-hackers Fri Oct 20 15:45:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA23844 for hackers-outgoing; Fri, 20 Oct 1995 15:45:20 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA23839 for ; Fri, 20 Oct 1995 15:45:17 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id RAA29737; Fri, 20 Oct 1995 17:44:11 -0500 From: Joe Greco Message-Id: <199510202244.RAA29737@brasil.moneng.mei.com> Subject: Re: Bragging rights.. To: dennis@etinc.com (dennis) Date: Fri, 20 Oct 1995 17:44:11 -0500 (CDT) Cc: hackers@freebsd.org In-Reply-To: <199510201901.PAA01704@etinc.com> from "dennis" at Oct 20, 95 03:01:57 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > I'm just going by what Jordan said.......... Well that's hardly a reasonable thing to do if you're trying to sell your product :-) > >Given a sufficiently inexpensive sync serial card, physical control of both > >ends of the link (so that you don't have somebody charging you a fortune for > >the privilege of doing sync serial on a router port, etc), I think it could > >be a really good solution. I would do it myself. :-) > > If you can get an extras $50 or $100 a month the price of the card is > recovered quite quickly. and since the smart sync uses less CPU at the hub, Yes, but most customers groan at the thought of yet another recurring fee... which is why this is a point _against_ sync, rather than _for_ it. Most places are looking for economical solutions. If they have to purchase a sync card that will cost them more and they may potentially have zero use for in a few months when they decide the Internet thing isn't for them, AND they have to pay higher fees to utilize it, what do you think they will do? > you get more use out of your hub CPU. Its a selling point, for those that > want it. If you have an advantage over other ISPs then you can lure more > customers. Its just business. Not for everyone, of course. Of course it's a selling point - I know ISP's that will sell dead fish to customers, if their customers want it. But you seem to be missing my basic idea: I doubt most people would be willing to pay so much more for so little extra. If you have any doubts, see what happened with things like 16.8K and 19.2K modems. It's all market analysis. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Fri Oct 20 16:12:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA24594 for hackers-outgoing; Fri, 20 Oct 1995 16:12:21 -0700 Received: from werple.net.au (0@werple.mira.net.au [203.9.190.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA24589 for ; Fri, 20 Oct 1995 16:12:16 -0700 Received: from cimaxp1.UUCP (Ucimlogi@localhost) by werple.net.au (8.7/8.7) with UUCP id IAA26825 for hackers@freebsd.org; Sat, 21 Oct 1995 08:41:27 +1000 (EST) Message-Id: <199510202241.IAA26825@werple.net.au> X-Authentication-Warning: werple.net.au: Ucimlogi set sender to cimaxp1!jb using -f Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA18441; Sat, 21 Oct 1995 08:44:09 +1000 From: John Birrell Subject: Re: NetBSD/FreeBSD (pthreads) To: leisner@sdsp.mc.xerox.com (Marty Leisner) Date: Sat, 21 Oct 1995 08:44:09 +1000 (EST) Cc: hackers@freebsd.org, jb@cimlogic.com.au In-Reply-To: <9510201855.AA17636@gnu.mc.xerox.com> from "Marty Leisner" at Oct 20, 95 11:55:04 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk Marty, > > > Why would I want kernel level threads? We try to make do with what's available. I _need_ threads for some applications. I _wanted_ kernel level threads (and I probably still do), but we can be successful with user-space threads. And that's what matters to me. I'm not sure if you want answers to these... > > 1) does a debugger understand userlevel threads? Not to the extent that you can debug individual threads without seeing the other threads. But the debugger is still useful (and not completely useless!). > 2) if I run a threaded application under strace, with kernel > levels threads is may make some sense...with user level threads > there's all this junk in the way... True. It would be nice not to see the 'junk'. > 3) Anyone have good hard numbers about the differences between user/kernel > level threads on performance? No. We don't have a user-space implementation that works on a system with kernel threads. We would have just used the kernel threads (like we do under OSF/1^H^H^H^HDigital UNIX). 8-). > > Like I said, the mit package is awfully clever... > > > > -- > marty > leisner@sdsp.mc.xerox.com > Member of the League for Programming Freedom > > > -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 9600 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137 From owner-freebsd-hackers Fri Oct 20 16:17:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA24680 for hackers-outgoing; Fri, 20 Oct 1995 16:17:47 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA24675 for ; Fri, 20 Oct 1995 16:17:46 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id QAA00924; Fri, 20 Oct 1995 16:17:24 -0700 From: Julian Elischer Message-Id: <199510202317.QAA00924@ref.tfs.com> Subject: Re: Duplicating whole disks To: freebsd@fgate.flevel.co.uk (freebsd) Date: Fri, 20 Oct 1995 16:17:24 -0700 (PDT) Cc: hackers@FreeBSD.org, graham@flevel.co.uk In-Reply-To: from "freebsd" at Oct 20, 95 10:10:19 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 885 Sender: owner-hackers@FreeBSD.org Precedence: bulk the FASTES way (if the TO drive is bigger than the FROM drive) would be to use the SCSI COPY command using the scsi(8) command (asks one scsi device to read another..) this would not even utilise the SCSI adapter, let alone the cpu transfer would be somewhere in the range of the highest speed of the slower device. a more standard method (also assuming sizeof(TO) > sizeof(From)) would be dd if=FROM of=TO bs=64k e.g. dd if=/dev/rsd0 of=/dev/rsd1 (or rst0 to send to tape) bs=64k to do it as a file based copy, I suggest cd FROM; find . -xdev -depth -print|cpio -pdmuv TO > > > > Hi > > >From time to time we need to make exact copies of a large number of hard > drives partitioned with freebsd. > > The drives are external SCSIs. > > Opinions please on the most efficient and fastest method. > > Would you please Cc: graham@flevel.co.uk > > Thanks v. much > > > From owner-freebsd-hackers Fri Oct 20 17:24:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA25991 for hackers-outgoing; Fri, 20 Oct 1995 17:24:12 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA25986 ; Fri, 20 Oct 1995 17:24:08 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id RAA01021; Fri, 20 Oct 1995 17:23:53 -0700 From: Julian Elischer Message-Id: <199510210023.RAA01021@ref.tfs.com> Subject: Re: NetBSD/FreeBSD (pthreads) To: marino.ladavac@aut.alcatel.at Date: Fri, 20 Oct 1995 17:23:53 -0700 (PDT) Cc: jb%cimaxp1@werple.net.au, hackers@FreeBSD.org, proven@FreeBSD.org In-Reply-To: <9510201221.AA26512@atuhc16.aut.alcatel.at> from "marino.ladavac@aut.alcatel.at" at Oct 20, 95 01:22:07 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 4772 Sender: owner-hackers@FreeBSD.org Precedence: bulk > John Birrell says: [lots'o'stuff] > I think that it is important that you do talk with Chris P about the Pthreads implimentation because we don't want to have two competing camps in out system with regards to threads.. I see no reason why the libc changes can't be incorporated on one condition.. THAT THEY CAN BE COMPILED IN A MODE THAT LEAVES THEM AS THEY ARE. (or provably equivalent) man pages MUST be updated to match the changes.. (If this sounds like a lot of work for you, I appologise but remember that we are all doing this as a hobby and it's no-body's job to clean up after others..) As I said to the guys doing IPX support, I'm willing to import code that I don't have to do massive work on myself, and for which there has been sufficient scrutiny. I consider the blessings of any two of phk, jkh, davidg, dyson, bde or me as suffient (if I can get time to look at it) One ther thing I want is that various camps working on related items need to talk and send me a note that they have looked at each other's work, and that they have either: worked out a common set of patches, or worked out an agreed strategy for co-existance. under these guidelines: I'm willing to commit your changes if: you can talk to Cris P Login: proven@freebsd.org Name: Chris Provenzano Directory: /home/proven Shell: /bin/csh Office: PROVEN Last login Wed Oct 18 09:16 (PDT) on ttyp8 from JIMI.MIT.EDU No Mail. Mail forwarded to: proven@athena.mit.edu and work out a common angle of attack on the problem.. Chris is our guide on threads stuff in general but of course anyone more active could 'take over'.. We DO want to support pthreads (I have cthreads running at TFS) you might also want to talk to rminnich@Sarnoff.COM with regards to his rfork stuff.. I think it could be used to give a nice kernel threads/user-threads mix.. > > > No. Instead I've started talking to a few NetBSD folks about making libc > > support pthreads directly. The MIT implementation has duplicated _many_ of > > the libc functions, including the assembly language stuff like setjmp. This > > makes supporting the system (pthreads + opsys) more difficult than it needs > > to be. So we changed libc to allow for threads. We build it twice, once with a > > preprocessor definition _THREAD_SAFE and once without it. For the threaded > > version, a few extra source files are compiled. We always link against libc, > > never libpthread.a and _then_ libc. The MIT implementation tries to sit on top > > of a system like FreeBSD/NetBSD. We believe that it should be part of it. > > Amen! Or at least parallel to libc, on the same level (similar to libcrypt > approach.) I'd support it IN libc if it were optional but a parallel library made from the same sources would be as good.. > > > Our implementation is now so different to the one from MIT that I doubt they'd > > be receptive to changes that affect their basic design. [Sorry if I have jumped > > to the wrong conclusion]. I think it's important that you talk to ChrisP. I'd like to support you, but if I do it mustn't exclude what he's doing.. it might even be possible for him to see the benefits in what you've done.. > > We're a bit behind with FreeBSD. You guys move so quickly... 8-). you should get a sup feed of the cvs tree for the kernel and libc if you plan on doing this.. > > > We've ported all our non-threaded code to FreeBSD (2.0.5R). With the exception > > of the function in the kernel which locates SYSVSHM segments, there were no > > problems. (NetBSD fixed SYSVSHM a few months ago. 2.0.5R behaves as NetBSD > > did). We wil accept patches to fix this relative to 2.2-current sources if you are able to submit them.. We want to support our users.. but we can't find all the fixes ourselves. > > Are you prepared to consider changing the FreeBSD libc to allow the _option_ > > of building a threaded version? Do you prefer keeping a separate libpthread > > like MIT builds? Are you using the MIT pthreads under FreeBSD? I'm not using them but I believe several people are. some libc fixes come under "General multithreading improvements" and can definitly go straight into libc. maybe we might have to have two subsiduary libraries libmitpthreads.a ;) and lib???pthreads.a possibly built from the same sources with different compile options.. > > I can speak only of myself, as I am definitely no project member. Yes, I do. > I would also be very interested in making the FreeBSD libc thread safe or > multithreaded as well. Keeping the library parallel but separate from libc > has its own merits, though. Especially during development thereof. > > Any (other) takers? I'll support it for sure. but I can't do the work, just act as source tree contact. > From owner-freebsd-hackers Fri Oct 20 17:40:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA26567 for hackers-outgoing; Fri, 20 Oct 1995 17:40:25 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA26561 for ; Fri, 20 Oct 1995 17:40:20 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id BAA12431 for ; Sat, 21 Oct 1995 01:40:16 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id BAA10834 for hackers@freebsd.org; Sat, 21 Oct 1995 01:40:16 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id AAA12872 for hackers@freebsd.org; Sat, 21 Oct 1995 00:40:07 +0100 From: J Wunsch Message-Id: <199510202340.AAA12872@uriah.heep.sax.de> Subject: Re: DT2801 and DT2811 (data acq) drivers To: hackers@freebsd.org Date: Sat, 21 Oct 1995 00:40:06 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510201015.GAA17548@hda.com> from "Peter Dufault" at Oct 20, 95 06:15:18 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 315 Sender: owner-hackers@freebsd.org Precedence: bulk As Peter Dufault wrote: > > I have a DT2811 driver I'd like to move into -stable, ... I'm afraid this is too late (and beyond the purpose of -stable). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Fri Oct 20 19:34:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA29303 for hackers-outgoing; Fri, 20 Oct 1995 19:34:50 -0700 Received: from werple.net.au (0@werple.mira.net.au [203.9.190.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA29298 for ; Fri, 20 Oct 1995 19:34:47 -0700 Received: from cimaxp1.UUCP (Ucimlogi@localhost) by werple.net.au (8.7/8.7) with UUCP id MAA05412 for hackers@freebsd.org; Sat, 21 Oct 1995 12:33:08 +1000 (EST) Message-Id: <199510210233.MAA05412@werple.net.au> X-Authentication-Warning: werple.net.au: Ucimlogi set sender to cimaxp1!jb using -f Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA23919; Sat, 21 Oct 1995 12:36:00 +1000 From: John Birrell Subject: Re: NetBSD/FreeBSD (pthreads) To: ref.tfs.com!julian@werple.net.au (Julian Elischer) Date: Sat, 21 Oct 1995 12:35:59 +1000 (EST) Cc: hackers@freebsd.org, jb@cimlogic.com.au In-Reply-To: <199510210023.RAA01021@ref.tfs.com> from "Julian Elischer" at Oct 20, 95 05:23:53 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk Julian, > I think that it is important that you do talk with Chris P about the Pthreads > implimentation because we don't want to have two competing camps in out system > with regards to threads.. Chris sent me mail yesterday and I have sent a reply with an explanation of some of the issues we addressed. He pointed out that POSIX requires a global set of signal handlers. I guess you'd prefer to stick as close to POSIX as you can? We can live with a global set of signal handlers (like we do with OSF/1). It just seemed nice to do it thread by thread. 8-(. > I see no reason why the libc changes can't be incorporated on one condition.. > THAT THEY CAN BE COMPILED IN A MODE THAT LEAVES THEM AS THEY ARE. Agreed. We add -D_THREAD_SAFE when we compile/assemble a threaded version. Without this, the code preprocesses to virtually the same thing. I say 'virtually' because we often change: return(foo(bar)); to ret = foo(bar); #ifdef _THREAD_SAFE something #endif return(ret); > (If this sounds like a lot of work for you, I appologise but remember > that we are all doing this as a hobby and it's no-body's job > to clean up after others..) Many of the changes to libc code are minor. I'm not sure how the man pages should document the threaded behavio[u]r though. > > and work out a common angle of attack on the problem.. > Chris is our guide on threads stuff in general but of course > anyone more active could 'take over'.. > We DO want to support pthreads (I have cthreads running at TFS) Jordan tells me that he and davidg discussed the integration of pthreads into libc with Chris at USENIX and the discussion went "almost word-for-word" like the one we're now having. 8-). -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 9600 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137 From owner-freebsd-hackers Fri Oct 20 21:16:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA02648 for hackers-outgoing; Fri, 20 Oct 1995 21:16:54 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA02642 for ; Fri, 20 Oct 1995 21:16:51 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id VAA01397 for hackers@FreeBSD.org; Fri, 20 Oct 1995 21:16:49 -0700 From: Julian Elischer Message-Id: <199510210416.VAA01397@ref.tfs.com> Subject: A quick vote on pthreads PLZ To: hackers@FreeBSD.org Date: Fri, 20 Oct 1995 21:16:49 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 128 Sender: owner-hackers@FreeBSD.org Precedence: bulk A/port/package or B/new base part of the system? there will be some changes to libc to make it thread-safe too. I vote for B From owner-freebsd-hackers Fri Oct 20 21:24:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA02887 for hackers-outgoing; Fri, 20 Oct 1995 21:24:11 -0700 Received: from chemserv.umd.edu (chemserv.umd.edu [129.2.64.40]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA02881 for ; Fri, 20 Oct 1995 21:24:09 -0700 Received: from mocha.eng.umd.edu (mocha.eng.umd.edu [129.2.98.16]) by chemserv.umd.edu (8.7/8.7) with ESMTP id AAA17211; Sat, 21 Oct 1995 00:24:07 -0400 (EDT) Received: (chuckr@localhost) by mocha.eng.umd.edu (8.7/8.6.4) id AAA22274; Sat, 21 Oct 1995 00:24:07 -0400 (EDT) Date: Sat, 21 Oct 1995 00:24:06 -0400 (EDT) From: Chuck Robey To: Julian Elischer cc: hackers@FreeBSD.org Subject: Re: A quick vote on pthreads PLZ In-Reply-To: <199510210416.VAA01397@ref.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Fri, 20 Oct 1995, Julian Elischer wrote: > > A/port/package > or > B/new base part of the system? > > there will be some changes to libc to make it thread-safe too. > > I vote for B > B also. You mean kernel threads? ========================================================================== Chuck Robey chuckr@eng.umd.edu, I run FreeBSD-current on n3lxx + Journey2 Three Accounts for the Super-users in the sky, Seven for the Operators in their halls of fame, Nine for Ordinary Users doomed to crie, One for the Illegal Cracker with his evil game In the Domains of Internet where the data lie. One Account to rule them all, One Account to watch them, One Account to make them all and in the network bind them. From owner-freebsd-hackers Fri Oct 20 21:32:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA03037 for hackers-outgoing; Fri, 20 Oct 1995 21:32:55 -0700 Received: from schizo.cdsnet.net (mrcpu@schizo.cdsnet.net [204.118.244.32]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA03032 for ; Fri, 20 Oct 1995 21:32:47 -0700 Received: (from mrcpu@localhost) by schizo.cdsnet.net (8.6.12/8.6.9) id VAA20297; Fri, 20 Oct 1995 21:32:11 -0700 Date: Fri, 20 Oct 1995 21:32:10 -0700 (PDT) From: Jaye Mathisen To: Julian Elischer cc: hackers@FreeBSD.org Subject: Re: A quick vote on pthreads PLZ In-Reply-To: <199510210416.VAA01397@ref.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk B. > A/port/package > or > B/new base part of the system? Can't imagine a really good reason not to. From owner-freebsd-hackers Fri Oct 20 21:43:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA03141 for hackers-outgoing; Fri, 20 Oct 1995 21:43:53 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA03136 for ; Fri, 20 Oct 1995 21:43:52 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id VAA01450; Fri, 20 Oct 1995 21:43:33 -0700 From: Julian Elischer Message-Id: <199510210443.VAA01450@ref.tfs.com> Subject: Re: A quick vote on pthreads PLZ To: chuckr@eng.umd.edu (Chuck Robey) Date: Fri, 20 Oct 1995 21:43:32 -0700 (PDT) Cc: hackers@FreeBSD.org In-Reply-To: from "Chuck Robey" at Oct 21, 95 00:24:06 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 498 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > On Fri, 20 Oct 1995, Julian Elischer wrote: > > > > > A/port/package > > or > > B/new base part of the system? > > > > there will be some changes to libc to make it thread-safe too. > > > > I vote for B > > > > B also. You mean kernel threads? no, not yet, (but it's on the way) this would be the pthreads user-level library, but it will EVENTUALLY grow kernel thread support when something happens to the kernel (The something might intitially be rfork() and may change later) julian From owner-freebsd-hackers Fri Oct 20 22:48:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA04291 for hackers-outgoing; Fri, 20 Oct 1995 22:48:46 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA04286 for ; Fri, 20 Oct 1995 22:48:39 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA05285; Sat, 21 Oct 1995 15:44:40 +1000 Date: Sat, 21 Oct 1995 15:44:40 +1000 From: Bruce Evans Message-Id: <199510210544.PAA05285@godzilla.zeta.org.au> To: julian@ref.tfs.com, mrcpu@cdsnet.net Subject: Re: A quick vote on pthreads PLZ Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk A. >B. >> A/port/package >> or >> B/new base part of the system? >Can't imagine a really good reason not to. Ifdef spaghetti. Bruce From owner-freebsd-hackers Fri Oct 20 23:34:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA05063 for hackers-outgoing; Fri, 20 Oct 1995 23:34:47 -0700 Received: from werple.net.au (0@werple.mira.net.au [203.9.190.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA05058 for ; Fri, 20 Oct 1995 23:34:44 -0700 Received: from cimaxp1.UUCP (Ucimlogi@localhost) by werple.net.au (8.7/8.7.1) with UUCP id PAA12308 for hackers@freebsd.org; Sat, 21 Oct 1995 15:58:19 +1000 (EST) Message-Id: <199510210558.PAA12308@werple.net.au> X-Authentication-Warning: werple.net.au: Ucimlogi set sender to cimaxp1!jb using -f Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA24133; Sat, 21 Oct 1995 16:01:14 +1000 From: John Birrell Subject: Re: A quick vote on pthreads PLZ To: ref.tfs.com!julian@werple.net.au (Julian Elischer) Date: Sat, 21 Oct 1995 16:01:14 +1000 (EST) Cc: hackers@freebsd.org, jb@cimlogic.com.au In-Reply-To: <199510210416.VAA01397@ref.tfs.com> from "Julian Elischer" at Oct 20, 95 09:16:49 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > > > A/port/package > or > B/new base part of the system? > Ummm. Do I have to leave the room? 8-). Just hoping everyone says B. -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 9600 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137 From owner-freebsd-hackers Fri Oct 20 23:41:52 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA05212 for hackers-outgoing; Fri, 20 Oct 1995 23:41:52 -0700 Received: from rover.village.org (rover.village.org [198.137.146.49]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA05189 for ; Fri, 20 Oct 1995 23:41:30 -0700 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id AAA09456 for ; Sat, 21 Oct 1995 00:41:10 -0600 Message-Id: <199510210641.AAA09456@rover.village.org> To: hackers@freebsd.org Subject: Problem with ptk-b8 .. ld problems already fixed? Date: Sat, 21 Oct 1995 00:41:09 -0600 From: Warner Losh Sender: owner-hackers@freebsd.org Precedence: bulk I'm trying to get pTk-p8 up and running on my FreeBSD 2.0 and got the following error. Look familiar to anybody? ld.so: Undefined symbol "__XInitImageFuncPtrs" in perl:./blib/auto/Tk/Tk.so Tk.so looks to be referencing X11, but can't seem to find this in libX11, even though it is in my copy (per nm output). Warner From owner-freebsd-hackers Sat Oct 21 00:09:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA05591 for hackers-outgoing; Sat, 21 Oct 1995 00:09:00 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA05586 for ; Sat, 21 Oct 1995 00:08:57 -0700 Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id AAA26703; Sat, 21 Oct 1995 00:08:45 -0700 Message-ID: <30889C7D.446B9B3D@FreeBSD.org> Date: Sat, 21 Oct 1995 00:08:45 -0700 From: "Jordan K. Hubbard" X-Mailer: Mozilla 2.0b1 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: John Birrell CC: Julian Elischer , hackers@FreeBSD.org, jb@cimlogic.com.au Subject: Re: NetBSD/FreeBSD (pthreads) References: <199510210233.MAA05412@werple.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk John Birrell wrote: > some of the issues we addressed. He pointed out that POSIX requires a global > set of signal handlers. I guess you'd prefer to stick as close to POSIX as > you can? We can live with a global set of signal handlers (like we do with > OSF/1). It just seemed nice to do it thread by thread. 8-(. Yes, it does. Any chance of making it a knob, so that the POSIX weenies can get the global behavior and those needing the other can have that too? Maybe a sysctl variable, set to POSIX compliance by default? -- Jordan From owner-freebsd-hackers Sat Oct 21 00:45:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA09172 for hackers-outgoing; Sat, 21 Oct 1995 00:45:36 -0700 Received: from rover.village.org (rover.village.org [198.137.146.49]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA09166 for ; Sat, 21 Oct 1995 00:45:32 -0700 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id BAA12213; Sat, 21 Oct 1995 01:44:59 -0600 Message-Id: <199510210744.BAA12213@rover.village.org> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) Subject: Re: xterm dumps core Cc: "Kaleb S. KEITHLEY" , Terry Lambert , hackers@freefall.freebsd.org In-reply-to: Your message of Thu, 19 Oct 1995 21:17:59 +0300 Date: Sat, 21 Oct 1995 01:44:59 -0600 From: Warner Losh Sender: owner-hackers@FreeBSD.org Precedence: bulk : Your issue must be based on some statistics, i.e. somehow : approximately counts users who 1) upgrade to new system and : 2) don't upgrade their X. Here my thought on this subject. : Old 8859-1 locale names lives very short time (I naively follows X locale : naming convention when implement them). So user population : using old names is very small. And population who wan't : upgrade their X even smaller, moreover, solution for : them already exists: "upgrade your X". Personally, I'm unlikely to upgrade my X unless I have to. The X server I have now works, and I'm not inclinded to change unless forced to do so. The OS under it doesn't matter, and if I install a new OS that breaks something, that OS is broken. Period. I will not upgrade my X because of that, I will yell to have my OS fixed to work with the perfectly valid X that I had before. "Upgrade your X" is not an option for me, nor for many others. I have railed in the past on Linux groups because Linux tends to break the edges of binary compatibility often. I don't want to see FreeBSD do that at all. I don't care how the current squabble works itself out, so long as I am nor forced to upgrade my X release when I upgrade my OS release. Warner From owner-freebsd-hackers Sat Oct 21 00:50:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA09265 for hackers-outgoing; Sat, 21 Oct 1995 00:50:42 -0700 Received: from rover.village.org (rover.village.org [198.137.146.49]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA09260 for ; Sat, 21 Oct 1995 00:50:32 -0700 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id BAA12226; Sat, 21 Oct 1995 01:49:14 -0600 Message-Id: <199510210749.BAA12226@rover.village.org> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) Subject: Re: xterm dumps core Cc: "Kaleb S. KEITHLEY" , hackers@freefall.freebsd.org In-reply-to: Your message of Thu, 19 Oct 1995 23:06:00 +0300 Date: Sat, 21 Oct 1995 01:49:13 -0600 From: Warner Losh Sender: owner-hackers@FreeBSD.org Precedence: bulk : What you count as "prior releases" is ONLY ONE INTERIM RELEASE: : 2.0.5! 8859-1 locale isn't supported in 2.0 yet. 2.0.5 not treated : as full release, it is only short term solution, so please stop : talking about "prior releases" and of incredible amount of their : users who wants backward compatibility. 2.0.5 is a release. It walks like a release, talks like a release, installs off a CD rom like a release. It is a release. Compatibility with it must be maintained, imho. If I upgrade from that to 2.1, and things break, I'm going to be very upset. I doubt I'll be alone. Every other FreeBSD upgrade has just worked. 1.0 -> 1.1 -> 1.1.5 -> 2.0 -> 2.0.5. (well, modulo the flock problems that were acknowledged as a bug). It is my expectation as a user that the 2.0.5 -> 2.1 release will go the same way. Warner From owner-freebsd-hackers Sat Oct 21 01:44:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA18342 for hackers-outgoing; Sat, 21 Oct 1995 01:44:43 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA18324 for ; Sat, 21 Oct 1995 01:44:36 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id BAA22172; Sat, 21 Oct 1995 01:43:33 -0700 To: Warner Losh cc: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A.) Sender: owner-hackers@FreeBSD.org Precedence: bulk Chernov, Black Mage) , "Kaleb S. KEITHLEY" , Terry Lambert , hackers@freefall.freebsd.org Subject: Re: xterm dumps core In-reply-to: Your message of "Sat, 21 Oct 1995 01:44:59 MDT." <199510210744.BAA12213@rover.village.org> Date: Sat, 21 Oct 1995 01:43:33 -0700 Message-ID: <22169.814265013@time.cdrom.com> From: "Jordan K. Hubbard" > Personally, I'm unlikely to upgrade my X unless I have to. The X > server I have now works, and I'm not inclinded to change unless forced > to do so. The OS under it doesn't matter, and if I install a new OS > that breaks something, that OS is broken. Period. I will not upgrade I can't say that this is an altogether unreasonable attitude. Jordan From owner-freebsd-hackers Sat Oct 21 01:46:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA18772 for hackers-outgoing; Sat, 21 Oct 1995 01:46:21 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA18761 for ; Sat, 21 Oct 1995 01:46:16 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id BAA22810; Sat, 21 Oct 1995 01:45:48 -0700 To: Warner Losh cc: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A.) Sender: owner-hackers@FreeBSD.org Precedence: bulk Chernov, Black Mage) , "Kaleb S. KEITHLEY" , hackers@freefall.freebsd.org Subject: Re: xterm dumps core In-reply-to: Your message of "Sat, 21 Oct 1995 01:49:13 MDT." <199510210749.BAA12226@rover.village.org> Date: Sat, 21 Oct 1995 01:45:48 -0700 Message-ID: <22805.814265148@time.cdrom.com> From: "Jordan K. Hubbard" > Every other FreeBSD upgrade has just worked. 1.0 -> 1.1 -> 1.1.5 -> > 2.0 -> 2.0.5. (well, modulo the flock problems that were acknowledged > as a bug). It is my expectation as a user that the 2.0.5 -> 2.1 > release will go the same way. Sorry, I came into this late. Actually, Andrey, a 2.0.5 -> 2.1 upgrade is featured as part of the 2.1 installation and it does indeed assume that backwards compatibility will be maintained. I have always treated 2.0.5 as a full release and I don't know where you get the idea that it can somehow fall outside the "prior release" criteria. Warner is perfectly correct: 2.0.5 was a full release. Period. Jordan From owner-freebsd-hackers Sat Oct 21 03:55:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA24767 for hackers-outgoing; Sat, 21 Oct 1995 03:55:48 -0700 Received: from bunyip.cc.uq.oz.au (pp@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id DAA24739 for ; Sat, 21 Oct 1995 03:55:40 -0700 Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au id <24289-0@bunyip.cc.uq.oz.au>; Sat, 21 Oct 1995 20:55:26 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id TAA17448 for ; Sat, 21 Oct 1995 19:17:02 +1000 Received: by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id JAA11001; Sat, 21 Oct 1995 09:16:33 GMT Date: Sat, 21 Oct 1995 09:16:33 GMT From: Stephen Hocking Message-Id: <199510210916.JAA11001@netfl15a.devetir.qld.gov.au> To: hackers@freebsd.org Subject: Re: A quick vote on pthreads PLZ X-Newsreader: NN version 6.5.0 #1 Sender: owner-hackers@freebsd.org Precedence: bulk I vote B. > > >A/port/package >or >B/new base part of the system? > >there will be some changes to libc to make it thread-safe too. > >I vote for B -- I do not speak for the Worker's Compensation Board of Queensland - They don't pay me enough for that! From owner-freebsd-hackers Sat Oct 21 05:22:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA00579 for hackers-outgoing; Sat, 21 Oct 1995 05:22:33 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA00572 for ; Sat, 21 Oct 1995 05:22:27 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id NAA27510 ; Sat, 21 Oct 1995 13:22:19 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id NAA14108 ; Sat, 21 Oct 1995 13:22:18 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id NAA01337; Sat, 21 Oct 1995 13:11:56 +0100 (MET) From: Ollivier Robert Message-Id: <199510211211.NAA01337@keltia.freenix.fr> Subject: Re: A quick vote on pthreads PLZ To: julian@ref.tfs.com (Julian Elischer) Date: Sat, 21 Oct 1995 13:11:56 +0100 (MET) Cc: hackers@FreeBSD.org In-Reply-To: <199510210416.VAA01397@ref.tfs.com> from "Julian Elischer" at Oct 20, 95 09:16:49 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1224 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk It seems that Julian Elischer said: > A/port/package > or > B/new base part of the system? I vote for B too. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #0: Sat Oct 14 19:05:10 MET 1995 From owner-freebsd-hackers Sat Oct 21 05:23:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA00610 for hackers-outgoing; Sat, 21 Oct 1995 05:23:07 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA00601 for ; Sat, 21 Oct 1995 05:23:04 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id NAA27506 ; Sat, 21 Oct 1995 13:22:17 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id NAA14105 ; Sat, 21 Oct 1995 13:22:17 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id NAA01327; Sat, 21 Oct 1995 13:11:15 +0100 (MET) From: Ollivier Robert Message-Id: <199510211211.NAA01327@keltia.freenix.fr> Subject: Re: Problem with ptk-b8 .. ld problems already fixed? To: imp@village.org (Warner Losh) Date: Sat, 21 Oct 1995 13:11:15 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199510210641.AAA09456@rover.village.org> from "Warner Losh" at Oct 21, 95 00:41:09 am X-Operating-System: FreeBSD 2.2-CURRENT ctm#1224 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk It seems that Warner Losh said: > I'm trying to get pTk-p8 up and running on my FreeBSD 2.0 and got the > following error. Look familiar to anybody? The real 2.0 ? I ask this because I just build Tk-b8 yesterday and it runs fine. > ld.so: Undefined symbol "__XInitImageFuncPtrs" in perl:./blib/auto/Tk/Tk.so BTW Tk-b8 is impressive. It has a much cleaner syntax thanks to Perl 5 than it does with Tcl (sorry Peter and Jordan, I can't grok Tcl). -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #0: Sat Oct 14 19:05:10 MET 1995 From owner-freebsd-hackers Sat Oct 21 06:41:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA01448 for hackers-outgoing; Sat, 21 Oct 1995 06:41:08 -0700 Received: from Relay1.Austria.EU.net (relay1.Austria.EU.net [192.92.138.47]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA01442 for ; Sat, 21 Oct 1995 06:41:04 -0700 From: marino.ladavac@aut.alcatel.at Received: from aut.alcatel.at (dnisun.aut.alcatel.at) by Relay1.Austria.EU.net with SMTP id AA22793 (5.67b/IDA-1.5 for ); Sat, 21 Oct 1995 14:40:49 +0100 Received: from atuhc16 by aut.alcatel.at (4.1/SMI-4.1/AAA-1.29/main) id AA08599; Sat, 21 Oct 95 14:40:39 +0100 Message-Id: <9510211340.AA08599@atuhc16.aut.alcatel.at> Received: by atuhc16 (1.38.193.4/16.2) id AA07002; Sat, 21 Oct 1995 14:40:53 +0100 Subject: Re: A quick vote on pthreads PLZ To: julian@ref.tfs.com (Julian Elischer) Date: Sat, 21 Oct 95 14:40:52 MET Cc: hackers@freebsd.org In-Reply-To: <199510210416.VAA01397@ref.tfs.com>; from "Julian Elischer" at Oct 20, 95 9:16 pm Mailer: Elm [revision: 70.85] Sender: owner-hackers@freebsd.org Precedence: bulk > A/port/package > or > B/new base part of the system? > there will be some changes to libc to make it thread-safe too. > I vote for B Seconded! /Alby From owner-freebsd-hackers Sat Oct 21 07:27:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA02262 for hackers-outgoing; Sat, 21 Oct 1995 07:27:51 -0700 Received: from fang.cs.sunyit.edu (fang.cs.sunyit.edu [192.52.220.66]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA02257 for ; Sat, 21 Oct 1995 07:27:49 -0700 Received: (from chuck@localhost) by fang.cs.sunyit.edu (8.6.9/8.6.9) id KAA24021; Sat, 21 Oct 1995 10:27:39 -0400 Date: Sat, 21 Oct 1995 10:27:39 -0400 From: Charles Kenneth Green - PRC Message-Id: <199510211427.KAA24021@fang.cs.sunyit.edu> In-Reply-To: Julian Elischer "A quick vote on pthreads PLZ" (Oct 20, 9:16pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Julian Elischer Subject: Re: A quick vote on pthreads PLZ Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk On Oct 20, 9:16pm, Julian Elischer wrote: } Subject: A quick vote on pthreads PLZ } } A/port/package } or } B/new base part of the system? } } there will be some changes to libc to make it thread-safe too. } } I vote for B }-- End of excerpt from Julian Elischer B, definately... -- Charles Green UN*X System Administration 22 Powell Ave. Apt. B UN*X Security & Whitesboro, NY 13492 Programming From owner-freebsd-hackers Sat Oct 21 07:53:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA03042 for hackers-outgoing; Sat, 21 Oct 1995 07:53:17 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA03025 ; Sat, 21 Oct 1995 07:53:14 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id HAA17665; Sat, 21 Oct 1995 07:53:05 -0700 To: announce@freebsd.org cc: hackers@freebsd.org Subject: 2.1.0-951020-SNAP - 2.1 *Release Candidate* Date: Sat, 21 Oct 1995 07:53:05 -0700 Message-ID: <17663.814287185@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk Well, it's out! The 2.1 release candidate is now available for testing. Modulo whatever problems all of you find between now and the final build, this will be what you find in 2.1! The date for which we'll schedule the final build will be based significantly on initial feedback from this snapshot, so be sure and get your feedback in ASAP! Very few bug reports will mean that we'll assume 2.1 to be really solid and probably schedule the build for late sometime next week. Lots of bug reports, well, we'll have to look at the severity of said bugs.. :) Normally we'd call for an extended BETA period at this point, but as the 2.1-STABLE tree has more-or-less been in code freeze since 2.0.5 (maybe "code slush?") it was felt that it would probably bring in fairly limited returns for the amount of extra delay induced. Given the number of people who are quite impatient to see 2.1 sooner rather than later, we'll give the snapshot method a shot. There are a few small things known-missing or broken in this snapshot, and those things ARE scheduled to be added before 2.1 is built. However, it may still be instructive to list them here so that snapshot installers don't stumble over them: o The WEB configuration is unimplemented. o The package installer may or may not do the right thing with chained adds. I haven't had the chance to adequately test this, given my limited testing hardware (I'm using a laptop with an 120MB hard disk!). o Some instrumentation is probably missing from the configuration file mechanism. o The HTML documentation reader menu may need some work. o The commercial distribution is still the 2.0.5 version - this will be updated before the final 2.1 release. o The bindist now includes all documentation from /usr/share/doc. If this ends up blowing up some of the minimally configured systems, we may need to make an optional `doc' distribution sooner than planned. Though I also fixed many, many bugs in sysinstall between now and the previous snapshot, I may have introduced a few of my own and your feedback is, as always, greatly welcomed! If you find something broken or confusing, please tell me! I often get bug reports prefaced with "I hate to bother you, but.." or "I don't know if you want to hear about bug reports, but.." - Please! I *want* to hear about problems with this installation. You don't need to be shy about pointing them out, and I won't be offended if you do! :-) If you find problems outside of the installation, e.g. with kernel panics or erroneous applications behavior, you may also want to send your feedback to: stable@Freebsd.ORG Rather than just myself. This snapshot contains the same code that people on the 2.1-STABLE branch are now running, and if you find a more general non-install related problem then that's probably the best mailing list discuss it with. As always, thanks to all for testing this snapshot! This one is especially important, for the reasons already stated, so I hope that you can help us by test-installing this in as many different configurations as you can! This snapshot is available on: ftp://ftp.freebsd.org/pub/FreeBSD/2.1.0-951020-SNAP/ We also regret that a space crunch currently precludes our putting it on freefall.freebsd.org, as we usually do. Some of you may wish to wait until it hits your local mirror (ftp.cdrom.com is always pretty heavily loaded!). Thanks! Jordan From owner-freebsd-hackers Sat Oct 21 08:45:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA04837 for hackers-outgoing; Sat, 21 Oct 1995 08:45:24 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA04829 for ; Sat, 21 Oct 1995 08:45:18 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id MAA04981; Sat, 21 Oct 1995 12:00:10 -0400 Date: Sat, 21 Oct 1995 12:00:10 -0400 Message-Id: <199510211600.MAA04981@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Joe Greco From: dennis@etinc.com (dennis) Subject: ISDN: Sync vs Async. Was: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> If you can get an extras $50 or $100 a month the price of the card is >> recovered quite quickly. and since the smart sync uses less CPU at the hub, > >Yes, but most customers groan at the thought of yet another recurring fee... >which is why this is a point _against_ sync, rather than _for_ it. > >Most places are looking for economical solutions. If they have to purchase >a sync card that will cost them more and they may potentially have zero use >for in a few months when they decide the Internet thing isn't for them, AND >they have to pay higher fees to utilize it, what do you think they will do? First of all, you need to be a better marketeer, Joe. First you make it a trade-up option, not the default. Sure you can tech-talk the layman into almost anything, but you have FACTS to work with here. Second of all, you are simply lucky that the average joe doesn't know that you're cheating them by giving them 30% less bandwidth then they think. You'd be surprise how many customers you'll get when you tell them that your competitors are ripping them off. Ride the wave for now, and hope that your competitors don't figure it out first..... Personally, I would gladly pay an extra $50. a month for a 30% increase in bandwidth. Of course, I wouldn't buy ISDN for any amount...... Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sat Oct 21 09:20:52 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA06333 for hackers-outgoing; Sat, 21 Oct 1995 09:20:52 -0700 Received: from io.org (root@io.org [142.77.70.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA06319 for ; Sat, 21 Oct 1995 09:20:49 -0700 Received: from flinch.io.org (flinch.io.org [198.133.36.153]) by io.org (8.6.12/8.6.12) with SMTP id MAA16237; Sat, 21 Oct 1995 12:20:18 -0400 Date: Sat, 21 Oct 1995 12:20:26 -0400 (EDT) From: Brian Tao To: "Jordan K. Hubbard" cc: multimedia@rah.star-gate.com, hackers@FreeBSD.ORG Subject: Re: Bragging rights.. In-Reply-To: <17846.814081219@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk On Wed, 18 Oct 1995, Jordan K. Hubbard wrote: > > Well, this is half me needing to tell *somebody* and half actually > being informative since some of the people on this list have wanted to > test various FreeBSD audio/video apps with me and were frustrated that > I only had that dinkly little V.34 modem. Well no more! > > I have now joined Amancio in the extended peni^H^H^H^Hbandwidth ISDN > club! :-) See, I figure I can only afford a BRI anyway, which wouldn't give me bragging rights over anybody. So I've moved into the office (we've got cots, two kitchens, a bathroom and shower here). 10Mbps service from my box to our provider 3 floors above us. Beat that. :) [now we'll see who has a T3 pipe running to their site ;-) ] -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Sat Oct 21 09:49:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA07137 for hackers-outgoing; Sat, 21 Oct 1995 09:49:44 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA07131 for ; Sat, 21 Oct 1995 09:49:41 -0700 Received: by sovcom.kiae.su id AA26673 (5.65.kiae-1 ); Sat, 21 Oct 1995 19:44:38 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Sat, 21 Oct 95 19:44:38 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id TAA00712; Sat, 21 Oct 1995 19:43:28 +0300 To: Warner Losh , "Jordan K. Hubbard" Cc: hackers@freefall.freebsd.org, "Kaleb S. KEITHLEY" References: <22805.814265148@time.cdrom.com> In-Reply-To: <22805.814265148@time.cdrom.com>; from "Jordan K. Hubbard" at Sat, 21 Oct 1995 01:45:48 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Sat, 21 Oct 1995 19:43:28 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: xterm dumps core Lines: 38 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1838 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <22805.814265148@time.cdrom.com> Jordan K. Hubbard writes: >> Every other FreeBSD upgrade has just worked. 1.0 -> 1.1 -> 1.1.5 -> >> 2.0 -> 2.0.5. (well, modulo the flock problems that were acknowledged >> as a bug). It is my expectation as a user that the 2.0.5 -> 2.1 >> release will go the same way. >Sorry, I came into this late. >Actually, Andrey, a 2.0.5 -> 2.1 upgrade is featured as part of the >2.1 installation and it does indeed assume that backwards >compatibility will be maintained. I have always treated 2.0.5 as a >full release and I don't know where you get the idea that it can >somehow fall outside the "prior release" criteria. Warner is >perfectly correct: 2.0.5 was a full release. Period. Sigh... I plan to make locale aliasing (the same as X locale.alias does) in more comfortable 2.2 schedule... 2.0.5 8859-1 ctype is wrong in several places (fixed now in -current but I don't see this fix passed to 2.1 as I ask!), I doubt that anybody even could use 2.0.5 8859-1 locale efficiently, as its developer I can say that it was added per experimental basis, so I don't expect backward capability to it will even been demanded. Moreover, all 8859-1 links in share/locale are invalid, because fr_FR/LC_TIME != de_DE/LC_TIME f.e. Now I change my mind a bit because parsing locale.alias takes a lot time comparing to filesystem links following, parsing degradates program startup speed. Jordan, expect current links removing and creating a lot more newest ones (they will solve backward capability too). -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sat Oct 21 10:02:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA07304 for hackers-outgoing; Sat, 21 Oct 1995 10:02:05 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA07299 ; Sat, 21 Oct 1995 10:02:03 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id KAA26481; Sat, 21 Oct 1995 10:01:54 -0700 To: announce@freebsd.org cc: hackers@freebsd.org Subject: New record for installation floppy update! :-) Date: Sat, 21 Oct 1995 10:01:54 -0700 Message-ID: <26479.814294914@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk The install floppies for 2.1.0-951020-SNAP were just updated to fix some problems I just noticed with the Options editor and to make FTP timeout handling work properly (the latter has been broken since 2.0.5, but I just noticed it now after having an install time out). If you've grabbed this snapshot but haven't yet installed it, I would advise revisiting ftp.freebsd.org for the latest boot.flp image. fixit.flp and root.flp remain unchanged. Jordan From owner-freebsd-hackers Sat Oct 21 10:24:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA07772 for hackers-outgoing; Sat, 21 Oct 1995 10:24:03 -0700 Received: from uuneo.neosoft.com (uuneo.neosoft.com [206.109.1.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA07762 for ; Sat, 21 Oct 1995 10:24:00 -0700 Received: from ris1.UUCP (ficc@localhost) by uuneo.neosoft.com (8.7.1/8.7.1) with UUCP id MAA06352 for freebsd.org!hackers; Sat, 21 Oct 1995 12:08:53 -0500 (CDT) Received: by ris1.nmti.com (smail2.5) id AA06330; 21 Oct 95 11:14:19 CDT (Sat) Received: by sonic.nmti.com; id AA16036; Sat, 21 Oct 1995 11:42:48 -0500 From: peter@nmti.com (Peter da Silva) Message-Id: <9510211642.AA16036@sonic.nmti.com.nmti.com> Subject: Re: > 2 gig filesystems To: boot@waterw.com Date: Sat, 21 Oct 1995 11:42:47 -0500 (CDT) Cc: hackers@freebsd.org In-Reply-To: <199510202216.SAA00579@itchy.mosquito.com> from "Bruce Bauman" at Oct 20, 95 06:16:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk This looks like a FreeBSD dump problem. I'm forwarding this to the FreeBSD-Hackers list... > > > I'm running amanda on stock FreeBSD 2.0.5. One of my filesystems is > larger than 2 gig, but is nowhere near full of data. A level 0 dump > fails, with lots of DUMP: bread: lseek2 fails and I/O errors with > negative block numbers. Is my problem with dump, with amanda, or > elsewhere? Do I need the amanda patches for filesystems larger than 2 > gig? > > Otherwise, things are working great, but that one big filesystem is > important. > > Thanks alot. > > -- Bruce > From owner-freebsd-hackers Sat Oct 21 11:46:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA09289 for hackers-outgoing; Sat, 21 Oct 1995 11:46:32 -0700 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA09284 for ; Sat, 21 Oct 1995 11:46:26 -0700 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id TAA02810; Sat, 21 Oct 1995 19:45:08 +0100 From: Luigi Rizzo Message-Id: <199510211845.TAA02810@labinfo.iet.unipi.it> Subject: Re: 2.1.0-951020-SNAP - 2.1 *Release Candidate* To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sat, 21 Oct 1995 19:45:07 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <17663.814287185@time.cdrom.com> from "Jordan K. Hubbard" at Oct 21, 95 07:52:46 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2645 Sender: owner-hackers@freebsd.org Precedence: bulk The following comments apply to the 951005 shap, hopefully Jordan knows whether or not they also apply to the latest one (which I won't be able to get until late next week). INSTALL PROGRAM =============== * a note should be added to point out that one can mount existing filesystems using the "Partition" and "Label" menus. It works nicely (once you know how to do it...) * a WARNING message should appear when newfs is enabled on a partition (it happened to me that, after changing the mountpoint twice, the "newfs" flag turned on: luckily I realized that before it was too late!); * is it possible to define an existing partition as "SWAP" ? I couldn't figure out how to do this, except by deleting and then recreating the partition (but then I am not sure that you can guarantee that the partition is in the same place as before). * before exiting, the "Configure" menu tells you that it is going to invoke the editor on "/etc/exports", but an error message appeared, something like "ee: exited on signal ..." (disappeared too quickly to read it all!) and the system rebooted. RUNNING THE SYSTEM ================== * fdisk still defaults on the "d" partition (e.g. /dev/rwd0d), instead of looking at "/dev/rwd0" * fdisk says "ioctl: DIOCWLABEL not supported by device" While this is the expected behaviour (in Pisa they say "lo deve fare"), the message gives the user an unpleasant feeling that something went wrong. I would rather change the message in something like "ioctl: Warning: DIOCWLABEL not required for device" (I think this is already fixed in -current). KERNEL SOURCES ============== * in sys/i386/conf, LINT and files.i386 include the entries for many devices (ATAPI, "asc" etc.), while the corresponding files are not present in the kernel source distribution. If there are reasons not to include them in the "standard" distribution, how about including a snapshot of the -current kernel sources on the CDROM ? I consider this quite important. BTW: users which install from an ATAPI cdrom, find themselves with unaccessible CD once the installation is complete! Thanks Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 ==================================================================== From owner-freebsd-hackers Sat Oct 21 11:58:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA09416 for hackers-outgoing; Sat, 21 Oct 1995 11:58:23 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA09410 for ; Sat, 21 Oct 1995 11:58:20 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id LAA03207; Sat, 21 Oct 1995 11:56:51 -0700 Message-Id: <199510211856.LAA03207@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: dennis@etinc.com (dennis) cc: Joe Greco , hackers@freebsd.org Subject: Re: ISDN: Sync vs Async. Was: Bragging rights.. In-reply-to: Your message of "Sat, 21 Oct 1995 12:00:10 EDT." <199510211600.MAA04981@etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Oct 1995 11:56:51 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk >>> dennis said: > > >> If you can get an extras $50 or $100 a month the price of the card is > >> recovered quite quickly. and since the smart sync uses less CPU at the hu b, > > Hmm... Now, if you can show that the telcos charge about $100 for a 128kb T1 line then I can see your arguments for sync peripherals. v-site.net pays about $700/month for a fraction of a T1 (350kb) with the option to use a full T1 on demand and of course if v-site.net uses the full T1 the charges go up. It costs less than $100 for v-site.net to maintain my 128kb connected to my home via a Centrex configuration. In simple terms, I am an extension to v-site.net ISDN setup;for instance, to dial v-site.net all I do is dial an extension number. The reason that I get the $100/month rate is because I know one of the principals since my college days and I provide consultation to his busines.. Clearly, the T1 business is not oriented to the home market. Perhaps, cable modem combined with ISDN will be the best price permance model for the home. Regards, Amancio From owner-freebsd-hackers Sat Oct 21 11:59:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA09502 for hackers-outgoing; Sat, 21 Oct 1995 11:59:28 -0700 Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA09497 for ; Sat, 21 Oct 1995 11:59:26 -0700 Received: from localhost (localhost [127.0.0.1]) by precipice.shockwave.com (8.6.12/8.6.12) with SMTP id LAA27166; Sat, 21 Oct 1995 11:56:55 -0700 Message-Id: <199510211856.LAA27166@precipice.shockwave.com> To: Brian Tao cc: "Jordan K. Hubbard" , multimedia@rah.star-gate.com, hackers@freebsd.org Subject: Re: Bragging rights.. In-reply-to: Your message of "Sat, 21 Oct 1995 12:20:26 EDT." Date: Sat, 21 Oct 1995 11:56:53 -0700 From: Paul Traina Sender: owner-hackers@freebsd.org Precedence: bulk From: Brian Tao Subject: Re: Bragging rights.. On Wed, 18 Oct 1995, Jordan K. Hubbard wrote: [now we'll see who has a T3 pipe running to their site ;-) ] Grunt. From owner-freebsd-hackers Sat Oct 21 12:09:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA09765 for hackers-outgoing; Sat, 21 Oct 1995 12:09:46 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA09754 for ; Sat, 21 Oct 1995 12:09:44 -0700 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id PAA00470 for freebsd-hackers@freebsd.org; Sat, 21 Oct 1995 15:09:41 -0400 From: Charles Henrich Message-Id: <199510211909.PAA00470@crh.cl.msu.edu> Subject: Weird out-of-swap error To: freebsd-hackers@freebsd.org Date: Sat, 21 Oct 1995 15:09:40 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 478 Sender: owner-hackers@freebsd.org Precedence: bulk Just now my system hit the upper limit on swap and spiraled into vm death with processes being killed. As soon as I noticed it I exited out of X via control-alt-backspace when the console came back there was a weird message on the screen: 3:08pm crh> -- MARK -- At which point I rebooted to clear my swap. Any ideas? -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-hackers Sat Oct 21 12:12:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA09836 for hackers-outgoing; Sat, 21 Oct 1995 12:12:55 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA09831 for ; Sat, 21 Oct 1995 12:12:52 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id MAA03361; Sat, 21 Oct 1995 12:11:13 -0700 Message-Id: <199510211911.MAA03361@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Brian Tao cc: "Jordan K. Hubbard" , multimedia@rah.star-gate.com, hackers@freebsd.org Subject: Re: Bragging rights.. In-reply-to: Your message of "Sat, 21 Oct 1995 12:20:26 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Oct 1995 12:11:13 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk >>> Brian Tao said: > On Wed, 18 Oct 1995, Jordan K. Hubbard wrote: > > > > Well, this is half me needing to tell *somebody* and half actually > > being informative since some of the people on this list have wanted to > > test various FreeBSD audio/video apps with me and were frustrated that > > I only had that dinkly little V.34 modem. Well no more! > > > > I have now joined Amancio in the extended peni^H^H^H^Hbandwidth ISDN > > club! :-) > > See, I figure I can only afford a BRI anyway, which wouldn't give > me bragging rights over anybody. So I've moved into the office (we've > got cots, two kitchens, a bathroom and shower here). 10Mbps service > from my box to our provider 3 floors above us. Beat that. :) > > [now we'll see who has a T3 pipe running to their site ;-) ] > -- > Brian Tao (BT300, taob@io.org) Amancio in real life after the posts: Scratches his head, hmm... pulls a few hairs --- lets see what can I do . A few minutes later , he gets run out of the property management office for trying to convince the building owners to install a Microwave Tower on the roof of his building :) Amancio, AI128 From owner-freebsd-hackers Sat Oct 21 12:42:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10318 for hackers-outgoing; Sat, 21 Oct 1995 12:42:11 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA10312 for ; Sat, 21 Oct 1995 12:42:06 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id PAA05553; Sat, 21 Oct 1995 15:58:19 -0400 Date: Sat, 21 Oct 1995 15:58:19 -0400 Message-Id: <199510211958.PAA05553@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Amancio Hasty Jr." From: dennis@etinc.com (dennis) Subject: Re: ISDN: Sync vs Async. Was: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >>>> dennis said: > > > > >> If you can get an extras $50 or $100 a month the price of the card is > > >> recovered quite quickly. and since the smart sync uses less CPU at the hu > b, > > > > >Hmm... > >Now, if you can show that the telcos charge about $100 for a 128kb T1 line >then I can see your arguments for sync peripherals. I don't think that you understand this thread at all. We're talking about async ISDN vs sync ISDN, which has nothing to do with fractional T1 which you are referencing. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sat Oct 21 12:56:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10744 for hackers-outgoing; Sat, 21 Oct 1995 12:56:42 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA10736 for ; Sat, 21 Oct 1995 12:56:39 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id UAA01631; Sat, 21 Oct 1995 20:56:36 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id UAA20577; Sat, 21 Oct 1995 20:56:35 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id UAA18835; Sat, 21 Oct 1995 20:53:28 +0100 From: J Wunsch Message-Id: <199510211953.UAA18835@uriah.heep.sax.de> Subject: Re: Weird out-of-swap error To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Sat, 21 Oct 1995 20:53:28 +0100 (MET) Cc: freebsd-hackers@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510211909.PAA00470@crh.cl.msu.edu> from "Charles Henrich" at Oct 21, 95 03:09:40 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 491 Sender: owner-hackers@freebsd.org Precedence: bulk As Charles Henrich wrote: > > processes being killed. As soon as I noticed it I exited out of X via > control-alt-backspace when the console came back there was a weird message on > the screen: > > 3:08pm crh> -- MARK -- You are not causing these messages by accident with some program calling logger(1)? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Oct 21 12:56:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10762 for hackers-outgoing; Sat, 21 Oct 1995 12:56:46 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA10739 for ; Sat, 21 Oct 1995 12:56:40 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id UAA01635; Sat, 21 Oct 1995 20:56:37 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id UAA20578; Sat, 21 Oct 1995 20:56:37 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id UAA18862; Sat, 21 Oct 1995 20:55:48 +0100 From: J Wunsch Message-Id: <199510211955.UAA18862@uriah.heep.sax.de> Subject: Re: 2.1.0-951020-SNAP - 2.1 *Release Candidate* To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Sat, 21 Oct 1995 20:55:48 +0100 (MET) Cc: jkh@time.cdrom.com, hackers@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510211845.TAA02810@labinfo.iet.unipi.it> from "Luigi Rizzo" at Oct 21, 95 07:45:07 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 673 Sender: owner-hackers@freebsd.org Precedence: bulk As Luigi Rizzo wrote: > > The following comments apply to the 951005 shap, hopefully Jordan > knows whether or not they also apply to the latest one (which I won't > be able to get until late next week). > RUNNING THE SYSTEM > ================== > * fdisk still defaults on the "d" partition (e.g. /dev/rwd0d), > instead of looking at "/dev/rwd0" David has been pulling the fix into the 2.1 branch meanwhile: const char *disk; const char *disks[] = { "/dev/rwd0", "/dev/rsd0", "/dev/rod0", 0 }; -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Oct 21 12:58:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10808 for hackers-outgoing; Sat, 21 Oct 1995 12:58:12 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA10802 for ; Sat, 21 Oct 1995 12:58:10 -0700 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id PAA00751; Sat, 21 Oct 1995 15:58:04 -0400 From: Charles Henrich Message-Id: <199510211958.PAA00751@crh.cl.msu.edu> Subject: Re: Weird out-of-swap error To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 21 Oct 1995 15:58:04 -0400 (EDT) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199510211953.UAA18835@uriah.heep.sax.de> from "J Wunsch" at Oct 21, 95 08:53:28 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 327 Sender: owner-hackers@freebsd.org Precedence: bulk > You are not causing these messages by accident with some program > calling logger(1)? I've never written a program to use logger, and I've not seen it in the past year.. so probably not. -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-hackers Sat Oct 21 13:28:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA11287 for hackers-outgoing; Sat, 21 Oct 1995 13:28:43 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA11270 ; Sat, 21 Oct 1995 13:28:36 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id OAA17643; Sat, 21 Oct 1995 14:30:42 -0600 Date: Sat, 21 Oct 1995 14:30:42 -0600 From: Nate Williams Message-Id: <199510212030.OAA17643@rocky.sri.MT.net> To: "Jordan K. Hubbard" Cc: announce@freebsd.org, hackers@freebsd.org Subject: Re: New record for installation floppy update! :-) In-Reply-To: <26479.814294914@time.cdrom.com> References: <26479.814294914@time.cdrom.com> Sender: owner-hackers@freebsd.org Precedence: bulk Jordan K. Hubbard writes: > The install floppies for 2.1.0-951020-SNAP were just updated to fix > some problems I just noticed with the Options editor and to make FTP > timeout handling work properly (the latter has been broken since > 2.0.5, but I just noticed it now after having an install time out). Umm, forgive me for sounding naive, but where's the emergency holographic shell I need to startup up my SLIP connection? I can't find the shell anywhere during the install, and I *like* it. :( [ Yes, I'm taking the plunge and upgrading my long-suffering 2.0R home system to the newest SNAP] Nate From owner-freebsd-hackers Sat Oct 21 13:31:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA11391 for hackers-outgoing; Sat, 21 Oct 1995 13:31:04 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA11383 for ; Sat, 21 Oct 1995 13:31:01 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id NAA03863; Sat, 21 Oct 1995 13:30:50 -0700 Message-Id: <199510212030.NAA03863@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: dennis@etinc.com (dennis) cc: hackers@freebsd.org Subject: Re: ISDN: Sync vs Async. Was: Bragging rights.. In-reply-to: Your message of "Sat, 21 Oct 1995 15:58:19 EDT." <199510211958.PAA05553@etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Oct 1995 13:30:50 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk >>> dennis said: > >>>> dennis said: > > > > > > >> If you can get an extras $50 or $100 a month the price of the card is > > > >> recovered quite quickly. and since the smart sync uses less CPU at th e hu > > b, > > > > > > > >Hmm... > > > >Now, if you can show that the telcos charge about $100 for a 128kb T1 line > >then I can see your arguments for sync peripherals. > > I don't think that you understand this thread at all. We're talking about > async ISDN vs sync ISDN, which has nothing to do with fractional T1 which > you are referencing. > Oops, tnks for the clarification. Now what about hardware compression. My Ascend Pipeline 50 has hardware data compression.... Cheers, Amancio From owner-freebsd-hackers Sat Oct 21 14:08:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA12773 for hackers-outgoing; Sat, 21 Oct 1995 14:08:50 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA12738 ; Sat, 21 Oct 1995 14:08:40 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id PAA17778; Sat, 21 Oct 1995 15:10:58 -0600 Date: Sat, 21 Oct 1995 15:10:58 -0600 From: Nate Williams Message-Id: <199510212110.PAA17778@rocky.sri.MT.net> To: Nate Williams Cc: "Jordan K. Hubbard" , announce@freebsd.org, hackers@freebsd.org Subject: Re: New record for installation floppy update! :-) In-Reply-To: <199510212030.OAA17643@rocky.sri.MT.net> References: <26479.814294914@time.cdrom.com> <199510212030.OAA17643@rocky.sri.MT.net> Sender: owner-hackers@freebsd.org Precedence: bulk Nate Williams writes: > Jordan K. Hubbard writes: > > The install floppies for 2.1.0-951020-SNAP were just updated to fix > > some problems I just noticed with the Options editor and to make FTP > > timeout handling work properly (the latter has been broken since > > 2.0.5, but I just noticed it now after having an install time out). > > Umm, forgive me for sounding naive, but where's the emergency > holographic shell I need to startup up my SLIP connection? I can't find > the shell anywhere during the install, and I *like* it. :( OK, I setup my machine on the net to accept PPP connections, but unfortunately I can't get the PPP on VTY 3 to do anything. Anything I type on VTY3 just echo's back at me but doesn't do anything. Help, term, return, all do nothing. What am I doing wrong? I even read the install docs, but unfortunately they don't explain what I'm seeing right now. Nate From owner-freebsd-hackers Sat Oct 21 14:21:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA13376 for hackers-outgoing; Sat, 21 Oct 1995 14:21:43 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA13371 for ; Sat, 21 Oct 1995 14:21:38 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id PAA17874; Sat, 21 Oct 1995 15:23:57 -0600 Date: Sat, 21 Oct 1995 15:23:57 -0600 From: Nate Williams Message-Id: <199510212123.PAA17874@rocky.sri.MT.net> To: Nate Williams Cc: Nate Williams , "Jordan K. Hubbard" , hackers@freebsd.org Subject: Re: New record for installation floppy update! :-) In-Reply-To: <199510212110.PAA17778@rocky.sri.MT.net> References: <26479.814294914@time.cdrom.com> <199510212030.OAA17643@rocky.sri.MT.net> <199510212110.PAA17778@rocky.sri.MT.net> Sender: owner-hackers@freebsd.org Precedence: bulk [ New Install floppies ] > OK, I setup my machine on the net to accept PPP connections, but > unfortunately I can't get the PPP on VTY 3 to do anything. Followup. It appears that PPP on VTY3 doesn't work. None of the standard commands or anything else appears to work, and I'm not really able to debug it since my working system is down for this upgrade. :( I'm seeing: ppp ON > Note, there is no host name, and anything I type doesn't appear to go to the program. Even simple commands like 'show modem' are useless. Help Jordan, help! I'm upgrading and I can't get PPP up. *grin* Nate From owner-freebsd-hackers Sat Oct 21 14:34:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA13615 for hackers-outgoing; Sat, 21 Oct 1995 14:34:49 -0700 Received: from werple.net.au (0@werple.mira.net.au [203.9.190.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA13610 for ; Sat, 21 Oct 1995 14:34:45 -0700 Received: from cimaxp1.UUCP (Ucimlogi@localhost) by werple.net.au (8.7/8.7.1) with UUCP id HAA06205 for hackers@freebsd.org; Sun, 22 Oct 1995 07:30:59 +1000 (EST) Message-Id: <199510212130.HAA06205@werple.net.au> X-Authentication-Warning: werple.net.au: Ucimlogi set sender to cimaxp1!jb using -f Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA25252; Sun, 22 Oct 1995 07:10:07 +1000 From: John Birrell Subject: Re: NetBSD/FreeBSD (pthreads) To: FreeBSD.org!jkh@werple.net.au (Jordan K. Hubbard) Date: Sun, 22 Oct 1995 07:10:07 +1000 (EST) Cc: hackers@FreeBSD.org, jb@cimlogic.com.au In-Reply-To: <30889C7D.446B9B3D@FreeBSD.org> from "Jordan K. Hubbard" at Oct 21, 95 00:08:45 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.org Precedence: bulk > > John Birrell wrote: > > some of the issues we addressed. He pointed out that POSIX requires a global > > set of signal handlers. I guess you'd prefer to stick as close to POSIX as > > you can? We can live with a global set of signal handlers (like we do with > > OSF/1). It just seemed nice to do it thread by thread. 8-(. > > Yes, it does. Any chance of making it a knob, so that the POSIX weenies can get the > global behavior and those needing the other can have that too? Maybe a sysctl variable, > set to POSIX compliance by default? This is possible because the signal code is layered. > -- > Jordan > -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 9600 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137 From owner-freebsd-hackers Sat Oct 21 14:34:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA13636 for hackers-outgoing; Sat, 21 Oct 1995 14:34:54 -0700 Received: from werple.net.au (0@werple.mira.net.au [203.9.190.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA13616 for ; Sat, 21 Oct 1995 14:34:49 -0700 Received: from cimaxp1.UUCP (Ucimlogi@localhost) by werple.net.au (8.7/8.7.1) with UUCP id HAA06203 for hackers@freebsd.org; Sun, 22 Oct 1995 07:30:58 +1000 (EST) Message-Id: <199510212130.HAA06203@werple.net.au> X-Authentication-Warning: werple.net.au: Ucimlogi set sender to cimaxp1!jb using -f Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA25404; Sun, 22 Oct 1995 07:05:35 +1000 From: John Birrell Subject: Re: A quick vote on pthreads PLZ To: bde@zeta.org.au (Bruce Evans) Date: Sun, 22 Oct 1995 07:05:34 +1000 (EST) Cc: hackers@FreeBSD.org, jb@cimlogic.com.au In-Reply-To: <199510210630.QAA07233@godzilla.zeta.org.au> from "Bruce Evans" at Oct 21, 95 04:30:18 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.org Precedence: bulk > > >I believe there aren't that many changes in the base system.. > > >the diffs to libc are probably going in anyhow under #ifdef THREAD_SAFE > >.. > >so what is your vote? > > < 10 ifdefs: libc > > 100 ifdefs: ports > > I don't think the library can be made thread safe with < 100 changes. What True. > would it do with all the places that return a pointer to static storage? These fall into three categories: (1) Functions which have a *_r() reentrant equivalent like readdir_r which have extra arguments so that static storage is avoided. (2) Functions which malloc memory and return that instead. The MIT code does this in places. (3) Dunno what the solution is. > > Bruce > > -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 9600 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137 From owner-freebsd-hackers Sat Oct 21 14:53:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA14417 for hackers-outgoing; Sat, 21 Oct 1995 14:53:56 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA14412 for ; Sat, 21 Oct 1995 14:53:51 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id QAA00577; Sat, 21 Oct 1995 16:52:40 -0500 From: Joe Greco Message-Id: <199510212152.QAA00577@brasil.moneng.mei.com> Subject: Re: ISDN: Sync vs Async. Was: Bragging rights.. To: dennis@etinc.com (dennis) Date: Sat, 21 Oct 1995 16:52:40 -0500 (CDT) Cc: hackers@freebsd.org In-Reply-To: <199510211600.MAA04981@etinc.com> from "dennis" at Oct 21, 95 12:00:10 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > First of all, you need to be a better marketeer, Joe. I'm not a marketeer at all :-) But I have been around a hell of a long time (I remember when Milwaukee's only Internet link was 9600 bits per second) :-) I do have some idea as to what works and as to what doesn't. > First you make it a > trade-up option, > not the default. Sure you can tech-talk the layman > into almost anything, but you have FACTS to work with here. Well, that's fine. > Second of all, > you are simply lucky > that the average joe doesn't know that you're cheating them by giving them 30% > less bandwidth then they think. Cheating them? Buddy, in this business, people PAY for bandwidth. An ISP could really care less about the technology used to connect a customer's site - it only affects recurring monthly costs and startup costs, which are passed off to the customer anyways. What you're REALLY paying the ISP for is bandwidth! And if you drop in a technology that squeezes more data over the line, the ISP needs to take this into account in their overall strategy. A T1 can be split into over 30 64K async channels before reaching bandwidth overcommit, whereas it can only be split into 24 sync channels! That is a respectable impact on operations. If you get some wonder gizmo that does compression, only a stupid ISP would allow you to use it without charging you extra. Same principle. It might have something to do with why the monthly (bandwidth) fee for a 64K async ISDN connection is typically LESS than a 56K (sync) connection. Why is it that I keep getting the impression that you don't understand this? > You'd be surprise how many customers you'll get > when you tell them that your competitors are ripping them off. Ride the wave for > now, and hope that your competitors don't figure it out first..... And pray your customers are stupid enough to fall for such a simplistic scam. That's just plain old dirty marketing. Competitors are not "ripping them off". See below. > Personally, I would gladly pay an extra $50. a month for a 30% increase in > bandwidth. > Of course, I wouldn't buy ISDN for any amount...... $50/month more? HAHA! You're more naive than I thought. I hate to be the one to explain this, but ISP's are not out to be generous to their customers. The switch from sync to async is gonna run you more than that. Let's throw some Real World Numbers around. It costs an ISP maybe $2500 a month to drop a T1 to someplace respectable. Split 24 ways, that's about $104 a month. Split 31 ways, that's about $80 a month. Right there, it costs the ISP $24 a month more to provide that sync bandwidth just in the T1 cost per 64K sync channel (i.e. wholesale bandwidth cost) - for two channels, you're perilously close to the figure you named. Now, figure that it costs the ISP significantly more to provide a sync serial port to the customer. They're probably NOT going to be using an ET card in a FreeBSD box, but even if they do - I can purchase 32 async ports for a single FreeBSD box for about $600, and with all the trimmings I can build a respectable terminal server with 32 ports for less than $1500. That's about $47 per port, which I would typically split by 6 and add to a customer's monthly bill (so say $8/month). Now, for an ET based solution, let's assume I can stick 5 dual port sync cards in a box. Again, the cost to build the box itself is maybe $900, and each card is maybe $500, so my cost to build is around $3400, or $340 per port because I only get 10 ports. That's $57/month I would charge a customer for that port, in the best case where I filled a box! So now, costs to provide: 64K async ISDN = $80 + $8 = $88 64K sync ISDN = $104 + $57 = $161 128K async ISDN = $160 + $8 = $168 128K sync ISDN = $208 + $57 = $265 Just considering bandwidth and hardware costs - so this is essentially _wholesale_ pricing. Now we need to consider the cost of an ISDN line, ISP operation expenses (rent, salaries, related services, etc), and profit. Of course, you can use bandwidth overcommit to help reduce some portions of your expenses, but when it comes down to the bottom line, if you can get sync serial for just $50 per month more than async, your ISP is obviously either overcharging for async connections to begin with, or is gonna go out of business if they get too many sync customers. There's just no way. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Sat Oct 21 15:36:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA15484 for hackers-outgoing; Sat, 21 Oct 1995 15:36:59 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA15479 for ; Sat, 21 Oct 1995 15:36:56 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id SAA05887; Sat, 21 Oct 1995 18:51:52 -0400 Date: Sat, 21 Oct 1995 18:51:52 -0400 Message-Id: <199510212251.SAA05887@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Joe Greco From: dennis@etinc.com (dennis) Subject: Re: ISDN: Sync vs Async. Was: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk J. Greco writes... >> Second of all, >> you are simply lucky >> that the average joe doesn't know that you're cheating them by giving them 30% >> less bandwidth then they think. > >Cheating them? > Yes. Because they think their getting 128k (or 115k) and they're only getting 90K. Now if you TELL them that they're only getting 90K and thats what they're paying for, then thats OK...the way it should be. But if they think they're getting 115 or 128k for what their paying, then its being misrepresented. If I were your competitor my Newspaper adds would read (get full 128k with ET (Joe only gives you 90K)) I'd have so many more customers that I could eat the cost of the sync cards and laugh my way to the bank. >Buddy, in this business, people PAY for bandwidth. An ISP could really care >less about the technology used to connect a customer's site - it only >affects recurring monthly costs and startup costs, which are passed off to >the customer anyways. What you're REALLY paying the ISP for is bandwidth! >And if you drop in a technology that squeezes more data over the line, the >ISP needs to take this into account in their overall strategy. A T1 can be >split into over 30 64K async channels before reaching bandwidth overcommit, >whereas it can only be split into 24 sync channels! That is a respectable >impact on operations. Precisely. Charge for the bandwidth. You can charge MORE for sync, because you get more. I thought that the idea of being in business was to make money, one by having value-added services, each of which I make a small margin, and the other to get more customers by having something to offer that my competitor doesn't have. I'm getting the feeling that all of your customers must be residential, in which case you may not have an opportunity. db ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sat Oct 21 15:40:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA15564 for hackers-outgoing; Sat, 21 Oct 1995 15:40:26 -0700 Received: (from hsu@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA15552 ; Sat, 21 Oct 1995 15:40:24 -0700 Date: Sat, 21 Oct 1995 15:40:24 -0700 From: Jeffrey Hsu Message-Id: <199510212240.PAA15552@freefall.freebsd.org> To: boot@waterw.com Subject: Re: > 2 gig filesystems Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk This wouldn't happen to formerly be a 1.1 filesystem, would it? I used to have the same problem, then I gave up and newfs'ed a 2.0 fs and moved everything over. In any case, -current has some lseek patches which may fix your problem (didn't solve mine). From owner-freebsd-hackers Sat Oct 21 16:04:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA15866 for hackers-outgoing; Sat, 21 Oct 1995 16:04:13 -0700 Received: from meter.eng.uci.edu (root@meter.eng.uci.edu [128.200.85.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA15854 for ; Sat, 21 Oct 1995 16:04:05 -0700 Received: from newport.ece.uci.edu by meter.eng.uci.edu (8.7) id QAA18749; Sat, 21 Oct 1995 16:04:02 -0700 (PDT) Received: from localhost by newport.ece.uci.edu (8.7) id QAA06180; Sat, 21 Oct 1995 16:04:01 -0700 (PDT) Message-Id: <199510212304.QAA06180@newport.ece.uci.edu> To: Bruce Evans cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org Subject: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] In-reply-to: Your message of "Sat, 21 Oct 1995 12:50:02 PDT." <199510211950.MAA10580@freefall.freebsd.org> Date: Sat, 21 Oct 1995 16:04:00 -0700 From: Steven Wallace Sender: owner-hackers@freebsd.org Precedence: bulk > to get it right. First we need to catch up with 4.4lite2, which uses > macros to handle struct padding. Then we need to catch up with NetBSD, I hate that SCARG macro. It makes looking at the code harder to understand. Perhaps if we did something like: read(struct proc *p, void *v, int retval[]) { struct read_args /* { int fd; char *buf; u_int nbyte; } */ *uap = v; int fd = SCARG(uap, fd); char *buf = SCARG(uap, buf); u_int nbyte = SCARG(uap, nbyte); ... } That way we don't have SCARG all over the place, and this would prepare us for your static function idea. > which passes the args correctly (as void *). Then we need to handle > varargs functions and struct padding better. I think all the details > can be hidden in machine-generated functions so that the args structs > and verbose macros to reference them don't have to appear in the core > sources. I agree. I don't like SCARG references all over the place. I take it you are refering to your static inline idea. Why don't we just go for that? Or should we do something like my example in the interim? > semsys() and shmsys() syscall interfaces are BAD because they > multiplex several syscalls that have different types of args. > There was no reason to duplicate this sysv braindamage but now > we're stuck with it. NetBSD has reimplemented the syscalls properly > as separate syscalls #220-231. > I agree. This is yucky! I hereby request a plea of help from all you FreeBSD hackers! We need a better way to handle these syscall subcodes (as SYSV calls 'em). I would not call the NetBSD reimplementation as "proper", but it is nicer than what we got right now. Oh, I agree, for new programs compiled it should use those separate syscalls #220-231, but for compatability, the old syscalls will still have to handle the subcodes, and this would still be nasty if left the same. I have run into the same prob with subcodes implementing the ibcs2 emulation. What we need is a new, automatically generated, method of handling subcodes without a nasy if (code == SYS_xxx) ... One idea I have is to use special case for the number of parms. If it is < 0 then special handling should be taken. case -1: Get code from next parameter. case -2: Get code from next parameter (quad_t). case -3: code = (code >> 8) & 0xff; (for ibcs2 xenix emulation) Then use the function pointer as a pointer to a new sysent, and do it all over again (making sure no recursion). I think this solution makes everything generic, without a penalty in performance for normal syscalls. I would like to hear what you guys think and any other ideas you may have towards a "real" solution (if that is ever possible). Steven From owner-freebsd-hackers Sat Oct 21 16:56:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA17610 for hackers-outgoing; Sat, 21 Oct 1995 16:56:22 -0700 Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA17579 for ; Sat, 21 Oct 1995 16:56:11 -0700 Received: from localhost (localhost [127.0.0.1]) by precipice.shockwave.com (8.6.12/8.6.12) with SMTP id QAA00601; Sat, 21 Oct 1995 16:54:53 -0700 Message-Id: <199510212354.QAA00601@precipice.shockwave.com> To: Steven Wallace cc: Bruce Evans , CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] In-reply-to: Your message of "Sat, 21 Oct 1995 16:04:00 PDT." <199510212304.QAA06180@newport.ece.uci.edu> Date: Sat, 21 Oct 1995 16:54:51 -0700 From: Paul Traina Sender: owner-hackers@freebsd.org Precedence: bulk From: Steven Wallace Subject: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c s >>ysv_shm.c] > which passes the args correctly (as void *). Then we need to handle > varargs functions and struct padding better. I think all the details > can be hidden in machine-generated functions so that the args structs > and verbose macros to reference them don't have to appear in the core > sources. I agree. I don't like SCARG references all over the place. I take it you are refering to your static inline idea. Why don't we just go for that? Or should we do something like my example in the interim? This brings up a point I wanted to mention... While I realize this is a bit against the philosophy that some of the team members hold, which is that we should not rely on gcc-type functionality, I'd actually prefer to see things like SCARG and prototype-glue done as static inlines where appropriate. The reason being is that with a static inline, as you can enforce type checking with: static inline struct rntype * rt2rn (struct rttype *rt) { return (rntype *) rt; } as opposed to #define RT2RN(x) ((rntype *) (x)) I don't like relying on gcc, but if I wanted to draw a line in the sand, I'd much prefer to draw a line based upon gcc than pcc. The idea that folks are even still today coding variables with the 'register' tag* and trying to hand-optimize register utilization by re-using symbols** instead of letting the compiler do that sort of thing (it's almost always better than us) is pretty silly. Just a random comment prompted by this discussion. Paul * every time you use the register tag, your're strongly encouraging gcc to reserve a register for use by that variable. gcc, unlike pcc, already understands when it should and shouldn't use registers and can do this far better than we can, so it's a bad idea to hamstring gcc by stealing its registers away...if something should be kept in a register, it will be kept there **e.g: radix.c (I know, not out fault) register int temp_integer; temp_integer = foo << 3 + bar; y = temp_integer * something else; . . . temp_integer = bzork * fnord; temp_integer = temp_integer << gazook; instead of: int middle, end; middle = foo << 3 + bar; y = middle * something else; . . . end = bzork * fnord; end = end << gazook; In the later case, gcc is smart enough to allocate register storage for middle and end, when they are needed, but can free up that register for use elsewhere between those two sections of code. Not to mention that you can then used "useful" names instead of x, y, and/or temp. :-) From owner-freebsd-hackers Sat Oct 21 17:38:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA18608 for hackers-outgoing; Sat, 21 Oct 1995 17:38:48 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA18602 for ; Sat, 21 Oct 1995 17:38:45 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id RAA16168; Sat, 21 Oct 1995 17:38:27 -0700 To: Nate Williams cc: hackers@freebsd.org Subject: Re: New record for installation floppy update! :-) In-reply-to: Your message of "Sat, 21 Oct 1995 14:30:42 MDT." <199510212030.OAA17643@rocky.sri.MT.net> Date: Sat, 21 Oct 1995 17:38:27 -0700 Message-ID: <16166.814322307@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > Umm, forgive me for sounding naive, but where's the emergency > holographic shell I need to startup up my SLIP connection? I can't find > the shell anywhere during the install, and I *like* it. :( Tch tch.. Nate.. Following up to -announce! :-) The holo shell comes after the root floppy is loaded, as always? Jordan From owner-freebsd-hackers Sat Oct 21 17:44:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA18940 for hackers-outgoing; Sat, 21 Oct 1995 17:44:04 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA18935 for ; Sat, 21 Oct 1995 17:44:01 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id SAA18251; Sat, 21 Oct 1995 18:46:13 -0600 Date: Sat, 21 Oct 1995 18:46:13 -0600 From: Nate Williams Message-Id: <199510220046.SAA18251@rocky.sri.MT.net> To: "Jordan K. Hubbard" Cc: Nate Williams , hackers@freebsd.org Subject: Re: New record for installation floppy update! :-) In-Reply-To: <16166.814322307@time.cdrom.com> References: <199510212030.OAA17643@rocky.sri.MT.net> <16166.814322307@time.cdrom.com> Sender: owner-hackers@freebsd.org Precedence: bulk Jordan K. Hubbard writes: > > Umm, forgive me for sounding naive, but where's the emergency > > holographic shell I need to startup up my SLIP connection? I can't find > > the shell anywhere during the install, and I *like* it. :( > > Tch tch.. Nate.. Following up to -announce! :-) I know, I know. I fixed the next followup. > The holo shell comes after the root floppy is loaded, as always? I thought you told me you knew a way to get the holo shell running at the beginning of the install. Also, what about the PPP stuff? Nate From owner-freebsd-hackers Sat Oct 21 18:03:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA19567 for hackers-outgoing; Sat, 21 Oct 1995 18:03:47 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA19562 for ; Sat, 21 Oct 1995 18:03:45 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id SAA22969; Sat, 21 Oct 1995 18:03:26 -0700 To: Nate Williams cc: hackers@freebsd.org Subject: Re: New record for installation floppy update! :-) In-reply-to: Your message of "Sat, 21 Oct 1995 15:10:58 MDT." <199510212110.PAA17778@rocky.sri.MT.net> Date: Sat, 21 Oct 1995 18:03:26 -0700 Message-ID: <22967.814323806@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk [Nate: Please stop sending this stuff to announce! I'd think that after 3 years of this you'd have at least learned to read mail headers.. :-)] Guess I need to start pasting in a Reply-To again.. Anyway.. > OK, I setup my machine on the net to accept PPP connections, but > unfortunately I can't get the PPP on VTY 3 to do anything. Anything I > type on VTY3 just echo's back at me but doesn't do anything. Help, > term, return, all do nothing. What am I doing wrong? I even read the > install docs, but unfortunately they don't explain what I'm seeing right > now. Nothing does and you're doing nothing wrong. It would appear that ppp broke at some point with sysinstall, and I'm not exactly sure why though what I am sure of is that the process startup code for it looks fishy.. It might have worked (like oh so much else in sysinstall) only by sheer chance in 2.0.5, adn I've now gone back and significantly revamped that bit of code. I'm testing it now! Jordan From owner-freebsd-hackers Sat Oct 21 18:06:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA19617 for hackers-outgoing; Sat, 21 Oct 1995 18:06:08 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA19612 for ; Sat, 21 Oct 1995 18:06:06 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id SAA22989; Sat, 21 Oct 1995 18:05:50 -0700 To: Nate Williams cc: hackers@freebsd.org Subject: Re: New record for installation floppy update! :-) In-reply-to: Your message of "Sat, 21 Oct 1995 15:23:57 MDT." <199510212123.PAA17874@rocky.sri.MT.net> Date: Sat, 21 Oct 1995 18:05:50 -0700 Message-ID: <22987.814323950@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > Note, there is no host name, and anything I type doesn't appear to go to > the program. Even simple commands like 'show modem' are useless. > > Help Jordan, help! I'm upgrading and I can't get PPP up. *grin* I will have a new boot floppy for you to try very shortly! In fact, you can ftp it straight from my machine, time.cdrom.com, right now or wait until I've tested it enough to drop it onto wcarchive. My latest post-951020 snapshop is there now with many of my fixes. Jordan From owner-freebsd-hackers Sat Oct 21 18:33:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA20291 for hackers-outgoing; Sat, 21 Oct 1995 18:33:33 -0700 Received: from wdl1.wdl.loral.com (wdl1.wdl.loral.com [137.249.32.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA20285 for ; Sat, 21 Oct 1995 18:33:31 -0700 Received: from miles.sso.loral.com (miles.wdl.loral.com) by wdl1.wdl.loral.com (5.x/WDL-2.4-1.0) id AA05277; Sat, 21 Oct 1995 18:32:58 -0700 Received: by miles.sso.loral.com (4.1/SSO-SUN-2.04) id AA25690; Sat, 21 Oct 95 21:32:40 EDT Date: Sat, 21 Oct 1995 21:32:39 -0400 (EDT) From: Richard Toren X-Sender: rpt@miles To: hackers@freebsd.org Subject: Re: A quick vote on pthreads PLZ Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Before throwing about the word POSIX, I think that a proposal of exactly what you are intending if this is put in as part of the base OS. Thread safe libraries? libc libC Sockets ... POSIX fork model for threaded code? Fork safe libraries as well? Implementing thread specifiec data (the array indexed by the key and thread id)? Signal handling? Has the FPU save/restore been fixed in pthreads recently? With the locking in the libraries, what will the gratutious mutex locking cost in time if the app is not threaded? Are we looking at truely preemptive threads ( all non-atomic reads are locked in the libraries)? Just some food for thought. I have used pthreads since this summer to practice threaded code analysis and construction, but I knew it was just a package, and had limitations. If it is advertised as being part of the OS, (and possibly POSIX) wil lit mislead people? ==================================================== Rip Toren | The bad news is that C++ is not an object-oriented | rpt@miles.sso.loral.com | programming language. .... The good news is that | | C++ supports object-oriented programming. | | C++ Programming & Fundamental Concepts | | by Anderson & Heinze | ==================================================== From owner-freebsd-hackers Sat Oct 21 18:38:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA20398 for hackers-outgoing; Sat, 21 Oct 1995 18:38:59 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA20389 for ; Sat, 21 Oct 1995 18:38:56 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id SAA26927; Sat, 21 Oct 1995 18:37:16 -0700 To: Paul Traina cc: Steven Wallace , Bruce Evans , CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] In-reply-to: Your message of "Sat, 21 Oct 1995 16:54:51 PDT." <199510212354.QAA00601@precipice.shockwave.com> Date: Sat, 21 Oct 1995 18:37:16 -0700 Message-ID: <26924.814325836@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > While I realize this is a bit against the philosophy that some of the > team members hold, which is that we should not rely on gcc-type > functionality, I'd actually prefer to see things like SCARG and Just FYI, it's never been mine. I routinely use structure initializers that only gcc grocks, and have even been known to do the occasional: { char foo[n]; .. } To do the job of alloca.. Not that I use the latter construct very often - I generally just use alloca directly, but the point is that if it's especially convenient to use gcc features, I use them. gcc now enjoys the deserved or undeserved privilege (take your pick) of being ubiquitous. I can't imagine porting to (or being interested in) any platform that did not support gcc, and if it did not then porting gcc would be my first task anyway! I say if advanced features make the code demonstrably cleaner, use them. Jordan From owner-freebsd-hackers Sat Oct 21 18:42:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA20546 for hackers-outgoing; Sat, 21 Oct 1995 18:42:39 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA20541 for ; Sat, 21 Oct 1995 18:42:37 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id SAA26980; Sat, 21 Oct 1995 18:42:20 -0700 To: Nate Williams cc: hackers@freebsd.org Subject: Re: New record for installation floppy update! :-) In-reply-to: Your message of "Sat, 21 Oct 1995 18:46:13 MDT." <199510220046.SAA18251@rocky.sri.MT.net> Date: Sat, 21 Oct 1995 18:42:20 -0700 Message-ID: <26978.814326140@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > I thought you told me you knew a way to get the holo shell running at > the beginning of the install. Ah. Not the holo shell, the *fixit* shell. The fixit takes over many of the functions of the holo shell, though that's started later. I still can't start it right away because it will clamp down on the floppy and I won't be able to remove it. I have to chroot once anyway, so I start things after I chroot it. > Also, what about the PPP stuff? Should be fixed! You can grab it right now from: ftp://time.cdrom.com/pub/2.1.0-951020-SNAP/floppies/boot.flp This is my test snapshot and please don't everyone start going to this location for FreeBSD in general - you'll swamp my home connection! :) Jordan From owner-freebsd-hackers Sat Oct 21 19:57:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA22290 for hackers-outgoing; Sat, 21 Oct 1995 19:57:30 -0700 Received: from werple.net.au (0@werple.mira.net.au [203.9.190.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA22285 for ; Sat, 21 Oct 1995 19:57:23 -0700 Received: from cimaxp1.UUCP (Ucimlogi@localhost) by werple.net.au (8.7/8.7.1) with UUCP id MAA07001 for hackers@freebsd.org; Sun, 22 Oct 1995 12:40:44 +1000 (EST) Message-Id: <199510220240.MAA07001@werple.net.au> X-Authentication-Warning: werple.net.au: Ucimlogi set sender to cimaxp1!jb using -f Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA25996; Sun, 22 Oct 1995 12:43:21 +1000 From: John Birrell Subject: Re: A quick vote on pthreads PLZ To: miles.sso.loral.com!rpt@werple.net.au (Richard Toren) Date: Sun, 22 Oct 1995 12:43:21 +1000 (EST) Cc: hackers@freebsd.org, jb@cimlogic.com.au In-Reply-To: from "Richard Toren" at Oct 21, 95 09:32:39 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > > Before throwing about the word POSIX, I think that a proposal of exactly > what you are intending if this is put in as part of the base OS. The proposal (at least as I see it) is to continue to build the normal libc with no compiled object size or performance impact. Non-threaded applications will continue to work as they always have. The issue of thread support being 'part of the base OS' is one of where the source code is live. The proposal is to add to the existing libc source in a way that allows the threaded library specific code to be pre-processed out when building the normal libc. The threaded version of libc will be compiled as a separate exercise. Those who don't want a threaded library won't have to build one. > Are we looking at truely preemptive threads ( all non-atomic reads are > locked in the libraries)? Yes. > > Just some food for thought. I have used pthreads since this summer to > practice threaded code analysis and construction, but I knew it was just > a package, and had limitations. If it is advertised as being part of the > OS, (and possibly POSIX) wil lit mislead people? Doubt it. > > ==================================================== > Rip Toren | The bad news is that C++ is not an object-oriented | > rpt@miles.sso.loral.com | programming language. .... The good news is that | > | C++ supports object-oriented programming. | > | C++ Programming & Fundamental Concepts | > | by Anderson & Heinze | > ==================================================== > -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 9600 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137 From owner-freebsd-hackers Sat Oct 21 20:00:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA22484 for hackers-outgoing; Sat, 21 Oct 1995 20:00:30 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA22477 for ; Sat, 21 Oct 1995 20:00:27 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id VAA18484; Sat, 21 Oct 1995 21:02:34 -0600 Date: Sat, 21 Oct 1995 21:02:34 -0600 From: Nate Williams Message-Id: <199510220302.VAA18484@rocky.sri.MT.net> To: "Jordan K. Hubbard" Cc: Nate Williams , hackers@freebsd.org Subject: Re: New record for installation floppy update! :-) In-Reply-To: <26978.814326140@time.cdrom.com> References: <199510220046.SAA18251@rocky.sri.MT.net> <26978.814326140@time.cdrom.com> Sender: owner-hackers@freebsd.org Precedence: bulk > > Also, what about the PPP stuff? > > Should be fixed! You can grab it right now from: > > ftp://time.cdrom.com/pub/2.1.0-951020-SNAP/floppies/boot.flp > > This is my test snapshot and please don't everyone start going to this > location for FreeBSD in general - you'll swamp my home connection! :) Cool, I'm grabbing it now. However, this floppy image was built around 2:00 this afternoon, and I didn't report the problems until after that. Did you read my mind and fix the problem before I reported it? :) Nate From owner-freebsd-hackers Sat Oct 21 23:29:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA26749 for hackers-outgoing; Sat, 21 Oct 1995 23:29:46 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA26744 for ; Sat, 21 Oct 1995 23:29:42 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA22831; Sun, 22 Oct 1995 16:27:01 +1000 Date: Sun, 22 Oct 1995 16:27:01 +1000 From: Bruce Evans Message-Id: <199510220627.QAA22831@godzilla.zeta.org.au> To: pst@shockwave.com, swallace@ece.uci.edu Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >While I realize this is a bit against the philosophy that some of the >team members hold, which is that we should not rely on gcc-type >functionality, I'd actually prefer to see things like SCARG and >prototype-glue done as static inlines where appropriate. 4.4lite already uses `static inline' extensively for vnode ops. I'd still like everything to work on non-gcc compilers. When `static' is defined to nothing, `static inline' should at most waste a lot of space and a little time... >The reason >being is that with a static inline, as you can enforce type checking >with: > static inline struct rntype * > rt2rn (struct rttype *rt) > { > return (rntype *) rt; > } >as opposed to > #define RT2RN(x) ((rntype *) (x)) ..or waste a lot of time if a lot of little functions like that aren't inlined :-). I would call that defeating type checking. You'll only get a warning if x has an incompatible type, not for the bogus cast. For syscall args I want something more like: static inline struct rntype * rt2rn (struct rttype *rt) { /* * Machine generated code to do the conversion. * Do not edit. */ #ifdef rt2rn_type_pun_works return (rntype *) rt; #else struct rntype rn = somealloc(sizeof *rn); rn->rn_foo = rt->rt_foo; rn->rn_bar = rt->rt_bar; return rn; #endif } >* every time you use the register tag, your're strongly encouraging > gcc to reserve a register for use by that variable. gcc, unlike pcc, > already understands when it should and shouldn't use registers and > can do this far better than we can, so it's a bad idea to hamstring I don't think use of `register' makes any difference for gcc for variables that can go in registers (i.e., auto variables whose address isn't taken). Bruce From owner-freebsd-hackers Sat Oct 21 23:32:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA26859 for hackers-outgoing; Sat, 21 Oct 1995 23:32:02 -0700 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id XAA26854 for ; Sat, 21 Oct 1995 23:31:59 -0700 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA20886 (5.65c8/HUTCS-S 1.4 for ); Sun, 22 Oct 1995 08:31:55 +0200 Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id IAA12224; Sun, 22 Oct 1995 08:32:05 +0200 Date: Sun, 22 Oct 1995 08:32:05 +0200 Message-Id: <199510220632.IAA12224@shadows.cs.hut.fi> From: Heikki Suonsivu To: Joe Greco Cc: freebsd-hackers@freefall.FreeBSD.org In-Reply-To: Joe Greco's message of 22 Oct 1995 00:01:22 +0200 Subject: Re: ISDN: Sync vs Async. Was: Bragging rights.. Sender: owner-hackers@FreeBSD.org Precedence: bulk Buddy, in this business, people PAY for bandwidth. An ISP could really care less about the technology used to connect a customer's site - it only affects recurring monthly costs and startup costs, which are passed off to the customer anyways. What you're REALLY paying the ISP for is bandwidth! Or IP priority. Pay twice the price customer B pays, see 2 packets gone for every packets B sends. If the links get sticky, customers up their priority, and ISP gets more money to buy more bandwidth (or takes the money Las Vegas and looses his customers, but that doesn't count :). Voila', a self-tuning free-market system. Typically home users are willing to settle for low priority and low price, and WWW service providers want high priority and are willing to pay for it. If you get some wonder gizmo that does compression, only a stupid ISP would allow you to use it without charging you extra. Same principle. Or one with routing technology which can prioritize customer's traffic according to the price they pay. The technology isn't there yet, though I have got a flakey proto written at HUT and I think someone else is also working on similar modifications. I have also heard cisco planning to do something like this. serial port to the customer. They're probably NOT going to be using an ET card in a FreeBSD box, but even if they do - I can purchase 32 async ports BTW, I have a $1000 (minus possible taxes) reward available for the author of a free driver for a commonly available synchronous serial card like SDL, ET or Arnet. Ie. sources available and non-restrictive license (preferably both GPL and Berkey to allow it to be included both in Linux and *BSD*). Need to talk to ciscos (that is what usually is in the other end). Needs to work and support multiple cards per machine. Preferably well-written (I think SDL and Arnet cards are both based on the same Hitachi 64570 chip so they could use common code). I know noone would write the driver from scratch just for just $1000, but maybe it could motivate someone to clean up his internal-purposes quick hack and release it :-). Anyone else willing to contribute? -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@clinet.fi home +358-0-8031121 work -4375360 fax -4555276

;;;;;;;;;; # lower ;;;;;;;;;;;;\ ;;