645 lines
25 KiB
Plaintext
645 lines
25 KiB
Plaintext
Subject: Linux-Development Digest #583
|
|
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
|
|
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 <Cn804G.7u9@info.bris.ac.uk>,
|
|
NJ. Bruton <ccnjb@sun.cse.bris.ac.uk> wrote:
|
|
>Byron A Jeff (byron@cc.gatech.edu) wrote:
|
|
>: In article <gat-240394180427@137.79.107.114>,
|
|
>: Erann Gat <gat@robotics.jpl.nasa.gov> 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 <distribution>.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 <jepstei@afterlife.ncsc.mil> 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 <CMs1B6.I42@frobozz.sccsi.com>:
|
|
>
|
|
>> 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 <jfh@rpp386.cactus.org> 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 <Cn6yFA.2uy@frobozz.sccsi.com> 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
|
|
******************************
|