Subject: Linux-Development Digest #583 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Sun, 27 Mar 94 12:13:07 EST Linux-Development Digest #583, Volume #1 Sun, 27 Mar 94 12:13:07 EST Contents: Re: Slackware as a tar.gz file? (Arthur Tateishi) DE620 Support ? URGENT ! (Chris.Caerts@esat.kuleuven.ac.be) Re: Xterm problem w/ 1.0 (bryan wright) Re: Linux and NEC Versa Notebook (SW Technology) Re: Slackware as a tar.gz file (Terry Gliedt) Linux PLIP (Bernard James Leach) bug/feature in fcntl syscall (David Monro) Re: How to use VARARGS under Linux ? (John Edward Tillema,&91M+soAj) remote diskless booting (Transformer) Re: Genoa Phantom ET4000/w32i + XFree86 anyone? (Jerry Shekhel) unsupported keys (scancode (xx) not in range 00 - 5f) (Kaz Sasayama) Re: [moddev README omission] Important (Erik Troan) ISDN driver sought (Felix von Leitner) Re: Amiga FileSystem, Anyone? (Kevin Brown) Re: A truely non-debugging Kernel? (Kevin Brown) Re: Amiga FileSystem, Anyone? (Kevin Brown) ---------------------------------------------------------------------------- From: ruhtra@turing.toronto.edu (Arthur Tateishi) Subject: Re: Slackware as a tar.gz file? Date: 25 Mar 94 17:11:02 GMT In article , NJ. Bruton wrote: >Byron A Jeff (byron@cc.gatech.edu) wrote: >: In article , >: Erann Gat wrote: >: >Does anyone have the Slackware 1.2.0 distribution assembled into a >: >tar file? It would be nice to be able to snarf the whole thing without >: >having to do fifty cds, lcds, and mgets. > >If you pull the distribution from sunsite.unc.edu or tsx-11.mit.edu you can >do a get of .tar.gz which pulls a tar gzipped directory Given that everything (well almost) in the slackware dir is gzip'ed, I usually get slackware.tar instead. Probably helps the load on sunsite, too. -- Choices don't scare me. However, a lack of choices does. Arthur Tateishi ruhtra@turing.utoronto.ca ------------------------------ Crossposted-To: comp.os.linux.help From: Chris.Caerts@esat.kuleuven.ac.be Subject: DE620 Support ? URGENT ! Date: Sat, 26 Mar 1994 01:24:08 GMT Dear netters, Is anyone working on a LINUX driver for the D-Link DE620 pocket ethernet adaptor ? We have to give a presentation which requires a local network consisting of two laptops, one running MSDOS and the other running LINUX (e.g. UNIX like system). THIS IS DUE NEXT FRIDAY. From the HOW_TO_ETHERNET, I learned that the DE620 adaptor, which we have, is not yet (known to be) supported, unlike the DE600 and the DE100 and DE200 series. If this is not possible, we will try to get PLIP running, although I do not know if that will work between a DOS and a LINUX machine. Any help appreciated. Many thanks in advance . Chris ------------------------------ From: bryan@pedro.phys.Virginia.EDU (bryan wright) Subject: Re: Xterm problem w/ 1.0 Date: Fri, 25 Mar 1994 16:12:27 GMT Hi again, Thanks to Carl Schott (cgschott@psu.edu), I've solved the problem. It turns out that somewhere in the pl15 series (after pl15a and before 1.0) NumLock was changed from initially ON to initially OFF for all VCs. See the note in drivers/char/keyboard.c under the linux kernel source directory. There are two solutions: First, you could change the definition of KB_DEFLEDS in keyboard.c to "(1 << VC_NUMLOCK)" and re-build the kernel. This would make NumLock ON by default, as it was originally. Second, you could get the kbd-0.85 package from tsx-11.mit.edu (or elsewhere). This includes the program "setleds" which allows you to easily turn NumLock, CapsLock, and ScrollLock on or off for a given VC. I've tried both these solutions, and each works. Thanks again to all who responded. Bryan -- =============================================================================== Bryan Wright |"If you take cranberries and stew them like Physics Department | applesauce, they taste much more like prunes University of Virginia | than rhubarb does." -- Groucho Charlottesville, VA 22901 | (804) 924-6814 | bryan@sphinx.phys.virginia.edu =============================================================================== ------------------------------ From: swt@netcom.com (SW Technology) Subject: Re: Linux and NEC Versa Notebook Date: Fri, 25 Mar 1994 18:43:38 GMT In article <2mis1o$pbr@hermes.acs.ryerson.ca> dburke@acs.ryerson.ca (Darryl Burke - ACPS/F93) writes: >Has anyone tried to get linux to run on a NEC Versa yet, i can get the base system to work fine, but "X" will complain about the vga card type... > >any suggestion?? maby the mono server or the VGA16 server???? > >Darryl Burke >dburke@turing.acs.ryerson.ca We sell the Versa E series with Linux/X preinstalled. You may try the Superpobe program to see what chip the video has and then put the chip in the Chipset entry of Xconfig. Email me if you have problem. -- Marvin Y. Wu || For great deals on PCs/PC parts, notebooks SW Technology || and Linux/386BSD/X workstations 251 West Renner Ste 229 || finger swt@netcom8.netcom.com, OR Richardson, TX 75080 || Anonymous FTP to ftp.netcom.com, and 214-907-0871 || cd /pub/swt/info for more infomation ------------------------------ From: zaphod!tpg@csn.org (Terry Gliedt) Subject: Re: Slackware as a tar.gz file Date: 25 Mar 1994 14:21:56 -0600 Reply-To: zaphod!tpg@csn.org > Does anyone have the Slackware 1.2.0 distribution assembled into a > tar file ? It would be nice to be able to snarf the whole thing without > having to do fifty cds, lcds, and mmgets. Check out Mftp from somewhere on sunsite.unc.edu. This is a graphical front-end to ftp which allows you to select a set of files/directories and FTP the lot of them. It'll make the target directory as it is needed. pretty slick, actually. =================================================================== Terry Gliedt (507) 356-4710 zaphod!tpg@csn.org ------------------------------ Crossposted-To: comp.os.linux.misc Subject: Linux PLIP From: leachbj@latcs1.lat.oz.au (Bernard James Leach) Date: Fri, 25 Mar 1994 13:14:09 GMT I was looking into PLIP for linux today and was reading the READM1.PLIP file. Now according to this Linux PLIP supports two different cables, one is a 4bit cable the other an 8 bit cable. Does anyone know anything further about this. From memory the 8 bit cable looked compatible with amiga plip! -- Bernard Leach - LaTrobe Uni Melb Australia cscbl@lux.latrobe.edu.au ------------------------------ From: davem@extro.ucc.su.OZ.AU (David Monro) Subject: bug/feature in fcntl syscall Date: Sun, 20 Mar 1994 16:02:31 GMT I discovered the following problem the other day while attempting to compile mtools-2.0.7 ( a suite of programs to access msdos floppies by attacking the raw floppy devices, avoiding having to mount them.) The problem is very simple - calling flock, or fcntl with appropriate args (same thing) on a block floppy device (ie /dev/fd0) fails with an 'Invalid argument' errno, but works fine for regular files. However, it appears to work on a Sun running SunOS 4.1.1 . Is this a bug or a feature? If it is a bug, I suspect the cause is on line 203 of linux/fs/locks.c, in the routine copy_flock(): if (!S_ISREG(filp->f_inode->i_mode)) return 0; Is there any reason locking should be restricted to regular files? The solution, for anybody out there compiling mtools, is to simply not define any of LOCKF, FLOCK and FCNTL. It works fine then, if a little unsafely. David Monro -- Rule of Feline Frustration: When your cat has fallen asleep on your lap and looks utterly content and adorable, you will suddenly have to go to the bathroom. -- "We demand rigidly defined areas of doubt and uncertainty!" -- Vroomfondel ------------------------------ From: tillemaj@news.doit.wisc.edu.UUCP (John Edward Tillema,&91M+soAj) Subject: Re: How to use VARARGS under Linux ? Date: 25 Mar 1994 21:07:49 GMT From article <1994Mar25.031012.3079@resonex.com>, by zenon@resonex.com (Zenon Fortuna): > Still, I cannot compile my sample VARARGS program, because a lot of > declarations are missing: Actually, I think you are probably just using the incorrect syntax. > my_log( va_alist ) > va_dcl > { > va_list argp ; > char *fmt ; > char string[ 5000 ] ; > > va_start( argp ) ; > fmt = va_arg( argp, char *) ; > vsprintf( string, fmt, argp ) ; > va_end( argp ) ; > puts( string ) ; > } I think this should be of the form: (don't know what va_dcl is?) void my_log(char fmt[], ... ) { va_list argp; va_start(argp,fmt); vfprintf(stdout,fmt,argp); /* or vsprintf(string,fmt,argp);puts(string) */ va_end(argp); } This will allow my_log to function just like a printf statement. > May be under Linux VARARGS are appied differently ? Not that I know of, seems to be the same as on Suns, and how its described in the C++ book where I learned it. John -- John Tillema tillemaj@cae.wisc.edu // \\// + 'nix Q: How many IBM cpu's does it take to do a logical right shift? A: 33. 1 to hold the bits and 32 to push the register. ------------------------------ From: wtyuan@Munchkin.Oz.nthu.edu.tw (Transformer) Subject: remote diskless booting Date: 27 Mar 1994 13:26:41 GMT Does any know that if there exists any remote diskless boot tool in Linux ? -- =========================================================================== Transformers for the peace fight! =========================================================================== ------------------------------ From: jerry@msi.com (Jerry Shekhel) Subject: Re: Genoa Phantom ET4000/w32i + XFree86 anyone? Date: 25 Mar 1994 22:26:46 GMT itusul@dale.ucdavis.edu wrote: : : That's strange...I tried one out for a day and got it to work under XFree : without any problems... : Works for me too. DX2/66, SiS Chipset Genoa Phantom W32i 8900VL XFree86-2.0 SVGA -- +-------------------+----------------------------+---------------------------+ | JERRY J. SHEKHEL | Molecular Simulations Inc. | Cowboy Junkies, Phish, | | Drummers do it... | Burlington, MA USA | Tribe, Guns N' Roses, | | ... In rhythm! | jerry@msi.com | TAMA, Zildjian, Linux... | +-------------------+----------------------------+---------------------------+ ------------------------------ From: kaz@lilia.iijnet.or.jp (Kaz Sasayama) Subject: unsupported keys (scancode (xx) not in range 00 - 5f) Date: 27 Mar 1994 18:56:35 +0900 My keyboard generates scancodes not in range 00 - 5f for some keys. How can I use them? This is the output of `showkey -s' in kbd-0.85: kb mode was XLATE press any key (program terminates after 10s of last keypress)... 0x9c 0x7b 0xfb 0x79 0xf9 0x70 0xf0 0x7d 0xfd The kernel is 1.0. Thanks in advance. -- "An AT-compatible for Linux, and for all of X68000 hackers." Kaz Sasayama (AKA sasayama@otsl.oki.co.jp) at home. ------------------------------ From: ewt@sunSITE.unc.edu (Erik Troan) Subject: Re: [moddev README omission] Important Date: 27 Mar 1994 15:03:28 GMT In article <1994Mar26.194716.18712@afterlife.ncsc.mil>, John Epstein wrote: >There is an important omission in moddev-0.1 README file. >The lines to add to rc.local should be >/sbin/insmod /sbin/moddev.o >modload & > >The README file omitted the "&" --- booting will not finish!!! >It did say modload runs in the background, which subtley implies >that the "&" is needed. Thanks for pointing this out. I've updated the README in the distribution file on sunsite to include the &, and updated the version number to 0.1a. Erik -- =========================================================================== "I'm not like that -- except when I am" ewt@sunsite.unc.edu = Erik Troan sasewt@unx.sas.com - Nora from "Pump up the Volume" ------------------------------ From: leitner@inf.fu-berlin.de (Felix von Leitner) Subject: ISDN driver sought Date: Fri, 25 Mar 1994 18:55:30 GMT Hi ! I Am am looking for ISDN drivers for ILinux. Please mail me where to find one ! Thanks, Felix -- (----------------------------------------------------------------) Felix von Leitner, Gervinusstrasse 22, 10629 Berlin, +49-30-3242987 President of the Council of Ultimate Wisdom High Druid of the Circle of the Ancient Shrub ------------------------------ From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: Amiga FileSystem, Anyone? Date: Thu, 24 Mar 1994 22:57:10 GMT In article <5L4sSp9jcsB@khms.westfalen.de> kai@khms.westfalen.de (Kai Henningsen) writes: >kevin@frobozz.sccsi.com wrote on 16.03.94 in : > >> a filesystem. Everything else is effectively variable: filename >> conventions, block size, directory layout, block allocation mechanisms, etc. > >> To me, then, the claim that some piece of software (I won't go so far as to >> say that DOS is an "operating system", but we've been through this before) >> supports "alternate filesystems" implies that it supports variability in >> the things that define the implementation of a filesystem. > >Now, would you say that a system that doesn't allow a binary of EMACS as a >legal filename has no "true" support for this, or do you accept that wha's >a legal filename is usually restricted in some way? As you so rightly point out, there are almost always going to be filename restrictions. Sigh. Nothing's ever easy, is it? :-) But that's not *quite* what I was saying, though I see your point. Linux supports variability in pretty much all the things that define the implementation of a filesystem, with one caveat: that you can't have null characters (because the API uses null-terminated strings) or "/" (because the API uses that as a directory separator character), and that you can't have "." or ".." as filenames (because the system uses those to denote current directory and parent directory). However, DOS supports *no* variability at all in filenames. It *insists* on the 8+3 rule, period. >Of course, you could say 8+3 is not enough (it's certainly uncomfortable), >but not on the grounds of your above arguments. > >By the way, what about mandatory locking? Is that an essential feature? >DOS has it. Mandatory locking? I would say that it's not an *essential* feature, in that many have managed quite well without it. However, that sounds like a feature that's not a part of the filesystem itself, but is, rather, a part of the kernel-filesystem interface, meaning that if you want mandatory locking, it would be implementable for all filesystems at once (or on a per-filesystem basis if you flag such a thing as part of the initialization). Look: ultimately, a filesystem just defines what data logically looks like on some kind of relatively permanent medium. The restriction linux places on filenames isn't really much of a restriction in filesystem terms since it doesn't place any limits on the layout of data on a disk (or other medium), except perhaps in the most bizarre cases. And, in any case, each restriction has good *functional* reason for being there, namely to insure that the programmers and users don't have to stand on their heads in order to specify a path, and to insure that it is *always* possible to specify the current directory and the parent directory. So if your emacs binary doesn't have any '/' or null characters in it (not bloody likely, I know, but still :-), then yes, you *can* use it as a legitimate filename, if the filesystem you want to use it on will support it. The DOS restriction on filenames is rather significantly different. It basically says that your filenames *will* look like: xxxxxxxx.xxx. That's not there for any good functional reason, either. It's there because of the historical roots of DOS. So they wanted CP/M programs to work under DOS. Big deal. They *could* have put an intermediate layer between CP/M and the actual filesystem, so that you could get the silly 8+3 restriction if you really wanted it, but that you didn't *have* to have it, but they didn't do that. I mean, even Unix used to have a 14-character filename limit, but at least the later kernel designs don't have that built into the kernel filename parsing algorithms (I somehow suspect it was never actually built into namei(), but I've never seen the actual code, so I don't *know*), i.e. it's not a prescribed limitation set in stone like the DOS 8+3 filename limitation. DOS doesn't simply say what your directory name entries *won't* look like (which is what Linux does), it says what your directory name entries *will* look like. Saying what your filenames *will* look like is a function of the filesystem, *not* of the kernel. It's the difference between saying "you can have everything but the kitchen sink" and saying "you can only have the kitchen sink". >> Linux has true alternate filesystem support, in that it leaves it up to the >> filesystem implementation to define such things as filename conventions, >> block allocation, directory layout, etc., and just defines the API you use >> to access the filesystem. >> >> DOS doesn't do this, if it defines what filenames are to look like (what > >Linux doesn't do that as well. Ever try to use the filename "/\0/" in a >filesystem? Ever try to use a regular file named "."? :-) Right. Linux defines what filenames *won't* look like. DOS defines what they *will* look like. See the difference? >> *else* do they define for you?). At best, one can say that DOS provides >> partial alternate filesystem support if, for instance, it doesn't insist >> on defining things like directory layout, block allocation, or other >> filesystem-dependent attributes. > >It doesn't. DOS can (and does) use filesystems like NFS or HPFS or ISO >9660. ...except that it can only use entries that conform to its limited concept of what a filename should be. Yeah, I suppose if there were entries with '/' or null, or entries named "." and "..", then Linux wouldn't be able to get at them, either. >> Regardless of the details, I suspect we all agree that the alternate >> filesystem support in DOS is suboptimal, at least when compared to the >> support found in (for instance) Linux. > >Considering the restrictions DOS is under, no, I don't agree. What restrictions are those? It just has to work with existing programs. That's not hard to do, because you don't have to change any existing system calls, just implement new ones. >It's not even so much DOS. I think DOS could learn to use more lenient >filename conventions, but that would break *lots* of programs. ...only the ones that go straight to the platter anyway. Such programs don't work with alternate filesystems (that DOS, in its own quirky fashion, supports now) anyway. Newly-written programs designed around the new set of system calls wouldn't be broken (but wouldn't be backward-compatible, either). >Kai >-- >Internet: kh@ms.maus.de, kai@khms.westfalen.de >Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai} >## CrossPoint v2.93 ## -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: A truely non-debugging Kernel? Date: Fri, 25 Mar 1994 00:19:42 GMT In article <2mfk5o$jfu@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Torvalds) writes: >In article <1994Mar19.153548.25480@rpp386>, >John F. Haugh II wrote: >> >>Yes, but none of this argues against using #ifdef to compile out the code. >>If a kernel runs fine for a month, isn't it time to assume that the same >>kernel will run fine for ANOTHER monther and even faster if you remove all >>the checks? >> >>You are looking at this wrong -- if you assume the kernel is going to crash >>all the time, you pay the penalties when it doesn't. AND, the user has no >>choice in the matter. > >I can only talk for myself: > > - I dislike #ifdef code. Avoid it whenever possible. #ifdefs become > ugly, and destroy the linearity of the code (== hard to read). Yup. But fortunately, you don't have to do that. When I write my code, I typically use something like: #define debug(x) x if I'm debugging my code and #define debug(x) when I'm not. Then, whenever I want debugging code inserted, I put it inside a debug() statement. This turns out to be fairly neat, clean, and (most importantly) *obvious*. > - I *do* assume the kernel is going to crash, and no, I don't > presonally like the idea of letting the user easily shut down some of > the sanity checks I write. Admittedly, they happen very seldom, and > they have a tendency to stay in even after I trust the code, but > you'd be surprised how many *hardware* bugs they've found. I would say, offhand, that it should be up to the user whether they run a safe kernel or not. After all, if their kernel dies on them and wreaks havoc, it's *their* fault that they compiled their kernel with sanity checks disabled, no? I would say that sanity checks turned on should definitely be the default, but not enforced. >Note that especially the latter one doesn't matter in user-level code, >but the kernel is rather special when it comes to debugging. If >somebody feels safe about it, let him edit out the stuff by hand. Personally, I'd rather have the sanity checks in place, but I certainly don't feel it's up to me to decide that for someone else. Of course, you, being God Incarnate, might feel differently. :-) :-) :-) P.S.: I'm a heathen, and I know it. I haven't yet played God's Own Rendition of The Right Way to Say "Linux"... :-) -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: Amiga FileSystem, Anyone? Date: Fri, 25 Mar 1994 01:00:57 GMT Sigh... In article kevin@frobozz.sccsi.com (Kevin Brown) writes: >But that's not *quite* what I was saying, though I see your point. Linux >supports variability in pretty much all the things that define the >implementation of a filesystem, with one caveat: that you can't have null >characters (because the API uses null-terminated strings) or "/" (because >the API uses that as a directory separator character), in filenames, of course... >and that you can't >have "." or ".." as filenames (because the system uses those to denote >current directory and parent directory). Umm...actually, it occurs to me that you *could* fix linux such that it would support every possible character in a filename, but that special characters (i.e., '/' and null) would have to be escaped with some magic escape character, and of course you'd have to escape the escape character to insert *it* into the filename as well. It would be gross, but it would work. I'd rather leave things as they are, myself. :-) The "." and ".." restriction is a bit tougher to get around, however... -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************