542 lines
23 KiB
Plaintext
542 lines
23 KiB
Plaintext
Subject: Linux-Development Digest #560
|
|
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: Thu, 17 Mar 94 10:13:11 EST
|
|
|
|
Linux-Development Digest #560, Volume #1 Thu, 17 Mar 94 10:13:11 EST
|
|
|
|
Contents:
|
|
Re: [Possible bug?] rm * on write-protected dos floppy (Johannes Stille)
|
|
Driver for precise delays: Driver etiquette? (Byron A Jeff)
|
|
DOS Emulator TCP/IP interface ? (Reuben Wells)
|
|
Re: 127.x.x.x (was Re: UDP report card) (Charles Hedrick)
|
|
SLIP, sl0 accounting (Arsenio Monteiro dos Reis - lisbbs SU)
|
|
Re: 127.x.x.x (was Re: UDP report card) (Matthias Urlichs)
|
|
IPX compliancy? (Mr Ivan Alastair Beveridge)
|
|
Re: Amiga FileSystem, Anyone? (Kevin Brown)
|
|
Re: DIP: tty: getc: I/O error (Kevin Brown)
|
|
Re: VT's must all use the same font [was Re: Loaded fonts discarded aft] (Kevin Brown)
|
|
Re: [Q] Unixware filesystem? (Michael K. Johnson)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: johannes@titan.westfalen.de (Johannes Stille)
|
|
Subject: Re: [Possible bug?] rm * on write-protected dos floppy
|
|
Date: Wed, 16 Mar 1994 20:24:01 GMT
|
|
|
|
In article <2m39g4$iss@wsdnws.cfi.waseda.ac.jp> 63912i@cfi.waseda.ac.jp ("Alexander During") writes:
|
|
>In article <2m1q0r$627@wswiop05.win.tue.nl> koen@wswiop05.win.tue.nl (Koen Holtman) writes:
|
|
[...]
|
|
>>
|
|
>>The Linux floppy drivers do not report write errors to the writing
|
|
>>program. This is more a case of broken-as-designed than an actual bug.
|
|
>>A real fix probably won't happen in the near future.
|
|
>>
|
|
>>> ---- Paul J. Gans [gans@acf2.nyu.edu]
|
|
>>Koen.
|
|
>
|
|
>I wonder whether there could be done something about this. Suppose you
|
|
[...]
|
|
|
|
Perhaps you should pay more attention to this newsgroup.
|
|
|
|
The problem is already solved. If you need details, please mail me. I
|
|
won't waste bandwidth by posting the patch again after just two weeks.
|
|
|
|
Linus has the patch, and I hope that it qualifies for the next kernel
|
|
release. BTW, the patch I posted back then had a bug left , so if you
|
|
have problems with it, please mail me. (Don't worry, it won't eat your
|
|
disks, at worst it could prevent floppy access.)
|
|
|
|
|
|
Johannes
|
|
|
|
------------------------------
|
|
|
|
From: byron@cc.gatech.edu (Byron A Jeff)
|
|
Subject: Driver for precise delays: Driver etiquette?
|
|
Date: Wed, 16 Mar 1994 23:07:28 GMT
|
|
|
|
A few days ago I posted a question concerning writing a device driver for
|
|
doing precise delays for a hardware programmer I'm building. I got a couple
|
|
of replies saying use more hardware for the delay but doing it precisely
|
|
will take up more space than I'm willing to give. Also I'm really interested
|
|
about learning about device driver development so this is a real opportun-
|
|
ity for me. I'm doing it as a device driver because I need to turn off
|
|
interrupts and I ran a test program to try that as root (in user space).
|
|
Didn't work. Also the kernel usleep function call is only accessible from
|
|
kernel space.
|
|
|
|
Anyway I've read the Kernel Hackers Guide and the source code and I have some
|
|
more questions:
|
|
|
|
1) As I asked the last time what will be the effect of having uninterruptable
|
|
100 uS delays for the rest of the system? Will anything break? The max
|
|
delay I saw in any other driver was 30 uS.
|
|
|
|
2) Do kernel space routines usually run with interrupts masked or unmasked?
|
|
|
|
3) If I cli() is there any exception in normal use that will interrupt a
|
|
process that is running between a cli() and an sti()?
|
|
|
|
4) What is the proper etiquette for doing init? For the character drivers
|
|
mem_init seems to have all the init calls for the other character drivers.
|
|
Would is be acceptable to hook my delay_init there?
|
|
|
|
5) Am I correct in assuming that the register_chrdev actually hooks your
|
|
driver to the rest of the kernel? The guide isn't real clear about that.
|
|
|
|
6) I know that for my own purposes that I can select a major number. However
|
|
is there a process by which a major number can be assigned if this
|
|
driver is of any use?
|
|
|
|
7) Dumb question: Why wasn't 7 assigned as a major number?
|
|
|
|
Now for the actual driver.
|
|
|
|
- character driver.
|
|
- init, open, write, and close implemented.
|
|
- doing a write will activate a hardware line on my programmer card,
|
|
delay for 100 uS, then deactivate the hardware line.
|
|
- The activation, delay, and deactivation will be done atomically by
|
|
turning off interrupts.
|
|
|
|
One issue that I see is that I'd like to control the flow of the delays so
|
|
that the system doesn't crawl to a halt while programming. Three ideas come
|
|
to mind:
|
|
|
|
- Use one of the PC hardware timers. the 8254 (or equivalent) has 3 timers.
|
|
Does Linux use all three? If not can I intercept one, program it for 100 uS
|
|
delays and generate an interrupt. However latency could be a problem because
|
|
that line needs to be activated for 100 uS +- 5 uS. Otherwise I get magic
|
|
smoke from my devices ;-)
|
|
|
|
- Somehow regulate the number of writes that can be done in a second. The
|
|
problem I see (and is a real hinderance to real-time programming under
|
|
linux) is that the jiffie clock is 100 Hz. Is it possible to specify
|
|
a sleep of less time then 10 ms? I figure if I can get about 2000 writes
|
|
per second will take %20 of the available time. But I need to be able
|
|
to sleep for 400 uS between writes.
|
|
|
|
- Instead of using the hardware timers to spcify the delay, use them to
|
|
give the inter-write delay. So a write would do a uninterruptable usleep
|
|
between wiggling the hardware line followed by a interruptable sleep after
|
|
turning on the timer that will interrupt after 400 uS or so. Since the
|
|
inter-write time is not critical if it's late (due to interrupt latency)
|
|
it's no problem.
|
|
|
|
Anyway I'm thinking that this might be a good example of a simple (very
|
|
simple) device driver and can show the minimal elements needed for a
|
|
device driver.
|
|
|
|
Any comments? Keep it out in the newsgroup so we can all talk about it.
|
|
|
|
BAJ
|
|
---
|
|
Another random extraction from the mental bit stream of...
|
|
Byron A. Jeff - PhD student operating in parallel!
|
|
Georgia Tech, Atlanta GA 30332 Internet: byron@cc.gatech.edu
|
|
|
|
------------------------------
|
|
|
|
From: row@bnr.co.uk (Reuben Wells)
|
|
Subject: DOS Emulator TCP/IP interface ?
|
|
Date: 17 Mar 1994 08:50:58 GMT
|
|
|
|
Hi,
|
|
|
|
Is there a command based interface to the DOS emulator via TCP/IP ?
|
|
The reason is simple, I have some commercial DOS programs (a compiler
|
|
and assembler for a microprocessor) and I want to be able to use
|
|
these from Linux and X. These programs only input and output text.
|
|
|
|
I would like to be able to start the DOS emulator on a socket
|
|
at boot time. I can then write wrapper Unix programs that
|
|
connect to the socket, cd to the correct directory and invoke
|
|
the programs returning the result. Why ? This has the illusion
|
|
that the programs are just normal Unix programs and allows the
|
|
use of tools like make. I can run them in any window and don't
|
|
have to keep moving between the DOS emulator and the X-term I
|
|
am working in. Also because it is always running it is not
|
|
necessary to have to wait for DOS to boot each time a command
|
|
is sent.
|
|
|
|
I am sure this must be relatively simple to do :-) Any idea/pointers
|
|
would be welcome,
|
|
|
|
Thanks,
|
|
|
|
Reuben
|
|
|
|
|
|
----------------------------------------------------
|
|
Reuben Wells (row@bnr.co.uk) Research Engineer
|
|
BNR Europe, London Road, Harlow, Essex, CM17 9NA
|
|
Tel: +44 (279) 403014 Fax: +44 (279) 402047
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: hedrick@geneva.rutgers.edu (Charles Hedrick)
|
|
Crossposted-To: comp.protocols.tcp-ip
|
|
Subject: Re: 127.x.x.x (was Re: UDP report card)
|
|
Date: 17 Mar 94 05:04:42 GMT
|
|
|
|
longyear@netcom.com (Alfred Longyear) writes:
|
|
|
|
>So, it is not the "implementation of TCP/IP" which is broken, but the
|
|
>operator's setup of the TCP/IP configuration which is broken. There is nothing
|
|
>"magical" about the address 127.0.0.1 other than the convention that it is the
|
|
>loopback device and is normally _configured_to_route_ back to your own machine.
|
|
|
|
Actually, there is something magical about 127: RFC 1122 and RFC 1009
|
|
both specify that 127 is a bogus address, and must never appear in
|
|
a packet that goes out of your machine.
|
|
|
|
------------------------------
|
|
|
|
From: arsenio@uc.pt (Arsenio Monteiro dos Reis - lisbbs SU)
|
|
Subject: SLIP, sl0 accounting
|
|
Date: Thu, 17 Mar 1994 09:46:46 GMT
|
|
|
|
Hi, i am managing a slip server, it has only one line, so all my clients
|
|
share the same ip adress, i would like to have a log reporting the trafic on
|
|
the sl0 interface, so i could know each user traffic, could someone point me
|
|
out some guidelines on how to do this? where in the kernel src is the code
|
|
regarding sl# interface, etc.
|
|
Thanx.
|
|
|
|
--
|
|
_
|
|
/_|
|
|
/ |rsenio Reis arsenio@lisbbs.uc.pt
|
|
Laboratorio de Informatica e Sistemas
|
|
Quinta da boavista lote I, 1
|
|
3000 Coimbra /---------------------------------------\
|
|
Portugal < Living in a box, a Linux Box. >
|
|
\---------------------------------------/
|
|
|
|
------------------------------
|
|
|
|
From: urlichs@smurf.noris.de (Matthias Urlichs)
|
|
Crossposted-To: comp.protocols.tcp-ip
|
|
Subject: Re: 127.x.x.x (was Re: UDP report card)
|
|
Date: 17 Mar 1994 12:03:30 +0100
|
|
|
|
In comp.os.linux.development, article <2m6g6r$ijk@gap.cco.caltech.edu>,
|
|
heathh@lust.ugcs.caltech.edu (Heath I Hunnicutt) writes:
|
|
>
|
|
> The difference is that the IP layer can make the correct decision not to put
|
|
> anything to 127.* on any external interface. The idea that someone should
|
|
> need to configure their system to not violate the RFCs is ridiculous. There
|
|
> is a large responsibility on the part of the stack to not allow stupid things
|
|
> like sending 127.* out on the net.
|
|
>
|
|
You can do a lot of stupid RFC-violating things with your network
|
|
configuration (and other parts of the kernel) that the fact that the
|
|
kernel doesn't regard 127.* as special doesn't bother me.
|
|
|
|
With newer BSD networking code, the fix is easy; just add
|
|
route add -reject -netmask 255.0.0.0 127.0.0.0 127.0.0.1
|
|
to the startup script. Voila, no more 127.* packets getting out.
|
|
|
|
> You really should research these issues before posting. For starters, see
|
|
> the Hosts Requirements RFC. There is indeed something "magical" about any
|
|
> address on the 127 net. Whether you set your system up with 127.0.0.1 as a
|
|
> loopback or not is your problem. No matter what, you should never send
|
|
> packets to 127.anything out any interface, regardless of the routing table's
|
|
> (mis)configuration.
|
|
|
|
Given that I've not heard of anybody who gets hurt by seeing spurious
|
|
127.anything_but_0_0_1 IP or ARP packets on the wire, I don't think special
|
|
code in the kernel to catch that case is all that necessary. Not if it can
|
|
be caught by a simple routint table entry.
|
|
|
|
--
|
|
A woman of generous character will sacrifice her life a thousand times over
|
|
for her lover, but will break with him for ever over a question of pride --
|
|
for the opening or the shutting of a door.
|
|
--Stendhal
|
|
--
|
|
Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.de
|
|
Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email.
|
|
90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
|
|
|
|
Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
|
|
|
|
------------------------------
|
|
|
|
From: zceed04@ucl.ac.uk (Mr Ivan Alastair Beveridge)
|
|
Subject: IPX compliancy?
|
|
Date: 17 Mar 1994 04:57:42 -0600
|
|
|
|
Basically, I was wondering if anyone has made Linux compliant with Netware
|
|
at all. As I do not really know much about protocols, I cannot really ask
|
|
much more than this.
|
|
|
|
Cheers
|
|
|
|
Ivan
|
|
--
|
|
|
|
|
|
Ivan Beveridge <zceed04@uk.ac.ucl>
|
|
|
|
------------------------------
|
|
|
|
From: kevin@frobozz.sccsi.com (Kevin Brown)
|
|
Subject: Re: Amiga FileSystem, Anyone?
|
|
Date: Wed, 16 Mar 1994 21:35:29 GMT
|
|
|
|
In article <5Kh9LndjcsB@khms.westfalen.de> kai@khms.westfalen.de (Kai Henningsen) writes:
|
|
>dholland@husc7.harvard.edu wrote on 10.03.94 in <DHOLLAND.94Mar10071127@husc7.harvard.edu>:
|
|
>
|
|
>> I believe the original point here was that DOS has no real workable
|
|
>> mechanism for handling alternate filesystems. I don't think the
|
|
>
|
|
>This, of course, is plainly wrong.
|
|
>
|
|
>> existence of the network redirector qualifies, because it's obscure,
|
|
>> messy, not necessarily supported, and still limits you to 8+3
|
|
>> character filenames, and various programs randomly don't work with it.
|
|
>
|
|
>1. Obscure & messy noes not mean it's not real workable.
|
|
>2. What do you mean, "not necessarily supported"?!
|
|
>3. *Of course* you are limited to 8+3 - that's DOS's *concept* of a
|
|
>filesystem.
|
|
|
|
Umm...then exactly what do you mean by "DOS handles alternate filesystems"?
|
|
Exactly what do you mean when you say "filesystem"?
|
|
|
|
I usually think of a filesystem simply as a mechanism for file storage.
|
|
You have some minimum set of operations (open, close, read, write, seek,
|
|
remove) that you can perform on it. Anything that doesn't at least
|
|
support that basic set of operations is not what I would consider to be
|
|
a filesystem. Everything else is effectively variable: filename conventions,
|
|
block size, directory layout, block allocation mechanisms, etc. If you can
|
|
support the above set of operations on, for instance, tar archives, then you
|
|
can legitimately claim that a tar archive is a "filesystem".
|
|
|
|
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.
|
|
|
|
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
|
|
*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.
|
|
|
|
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.
|
|
|
|
|
|
--
|
|
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: DIP: tty: getc: I/O error
|
|
Date: Wed, 16 Mar 1994 21:47:37 GMT
|
|
|
|
In article <1994Mar13.140017.293@ijssel.hacktic.nl> arnoudm@ijssel.hacktic.nl writes:
|
|
>Sys admin writes in newsgroup comp.os.linux.development:
|
|
>> * No gettys on the serial ports *
|
|
>> When I first boot my machine, I can run kermit as much as I want with no
|
|
>> problems. My first DIP script runs fine, but when I kill DIP
|
|
>> via kill -9 pid,
|
|
>
|
|
>Sys admins who complain about a system failure when they kill a
|
|
>system program with -9 signal should be forced to read a goood
|
|
>Unix book. Ever heard of proper clean up? Read the man-page: Dip
|
|
>provides the -k option which lets dip to do it's own clean up
|
|
>(even hangup the line).
|
|
|
|
Yup. However, user programs (i.e., those programs that are required to go
|
|
through the appropriate kernel calls to get to the filesystems and to the
|
|
hardware) should never be able to hose the system to the point of requiring
|
|
a reboot.
|
|
|
|
More to the point, even if the serial port is in a weird state, the
|
|
administrator should still be able to log into the console and set the
|
|
serial port to a sane state. The kernel shouldn't lock up just because
|
|
the serial port is in a weird state.
|
|
|
|
Of course, that's how things *should* be. I realize that such ideals are
|
|
difficult to achieve in practice...
|
|
|
|
>> enter kermit, enter hang command to hang up modem, I have to re-boot!
|
|
>> DIP now gives me the error in the subject, or sometimes it hangs when setting
|
|
>> the port to ttyS0. Kermit starts, then hangs untill I enter CTRL-C, which
|
|
>> brings me to the kermit prompt. When I enter 'connect' I get
|
|
>> Kermit -> Can't send character: I/O error.
|
|
>
|
|
>I am not sursprised.
|
|
|
|
Me neither.
|
|
|
|
|
|
--
|
|
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: VT's must all use the same font [was Re: Loaded fonts discarded aft]
|
|
Date: Wed, 16 Mar 1994 22:26:22 GMT
|
|
|
|
In article <CMnGDG.7Av@eecs.nwu.edu> hpa@nwu.edu (H. Peter Anvin) writes:
|
|
>In article <CMJzx9.CAz@cwi.nl> of comp.os.linux.development,
|
|
> aeb@cwi.nl (Andries Brouwer) writes:
|
|
>>
|
|
>> You asked this question before, and I answered it. Now you ask
|
|
>> it again, and the answer will be the same.
|
|
>> Several implementations of font loading code were floating around,
|
|
>> and I liked Crosser's version best, polished it a little and proposed
|
|
>> including it in the standard kernel, which Linus did.
|
|
>> [So, no behaviour was changed, but a choice was made.]
|
|
>>
|
|
>> Now should there be a separate font for each VT?
|
|
>> If everyone wants it, then yes. If many people want it, then
|
|
>> it should at least be a configuration option.
|
|
|
|
Actually, it shouldn't be a matter of choosing to have one variable
|
|
font for all consoles or support for separate fonts for each console.
|
|
Rather, the console code should reuse fonts that are already in
|
|
use, which means that font identifiers will need to be used, but
|
|
that shouldn't add much more overhead (only a few bytes) than what
|
|
you'd have if you were using a single loadable font for each console.
|
|
The data for the font would still dominate in the space usage
|
|
calculation. So if console 2 and console 1 are using the same
|
|
font, then that means that their font entries point to the same
|
|
font structure. Your font structure keeps a unique ID (perhaps
|
|
the path to the font? Something that you can use to detect whether
|
|
font change requests refer to the cached font or to some other
|
|
font) and a reference count, and when it goes to zero, you can free
|
|
it up (or mark that area for reuse by another font when you go to
|
|
load a new one).
|
|
|
|
Ideally, the font structure should simply contain the unique ID, the
|
|
reference count, and a pointer to the actual font. That way, you refer
|
|
to the ROM-based font by having the font structure's pointer point to it.
|
|
|
|
I haven't looked at the console source, so I can't say whether it's
|
|
possible to implement the above scheme. But if it is, then that's
|
|
how it should be done, IMHO. It buys you the efficiency and
|
|
relatively low overhead of a single font in the case that the *user*
|
|
doesn't want to have different fonts for each console, and gives
|
|
you the flexibility of having separate fonts for each console if
|
|
that's what the user wants.
|
|
|
|
>> But there is a danger of pollution: there are many potentially
|
|
>> nice things, and at configuration time one could easily have
|
|
>> fifty keyboard/console-related questions.
|
|
|
|
Nope. With the above, one simply asks "do you want loadable console
|
|
fonts?" and configures things appropriately. Indeed, I would think that
|
|
*not* configuring loadable fonts basically means that the code for
|
|
loading fonts isn't compiled in, but the font structure remains for
|
|
the purposes of initializing the consoles to point to the ROM-based font.
|
|
In short, it shouldn't save you *that* much to begin with. You could
|
|
thus easily justify making the loadable fonts module the default option.
|
|
|
|
>> Separate fonts for each VT take a lot of memory, and are used
|
|
>> by relatively few Linux users, so cannot be the default, I think.
|
|
>
|
|
>Two issues:
|
|
>
|
|
>1. I would assume support could be there; memory could me kmalloc()ed
|
|
>at load time if the font is loaded with the "set only this VT" option.
|
|
>Since the maximum size of a font is 32x256 = 8K, having two data block
|
|
>pointers/VT would do it. If set to NULL, use the global font.
|
|
|
|
As per above, any font should be usable by any set of consoles. There
|
|
shouldn't be a distinction between a "global font" and a "font only for
|
|
this VT". If anything, the only font that should get special treatment
|
|
is the ROM font. It would be ideal if the ROM font could be treated as
|
|
any other font (except that, at boot time, its reference count is set to
|
|
1 + NR_CONSOLES and all consoles are initialized to point to its font
|
|
structure, in order to insure that it is impossible to cause its reference
|
|
count to drop to zero even when all consoles are actually using RAM-based
|
|
fonts).
|
|
|
|
|
|
--
|
|
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: johnsonm@ladybird.oit.unc.edu (Michael K. Johnson)
|
|
Subject: Re: [Q] Unixware filesystem?
|
|
Date: 16 Mar 1994 01:04:21 GMT
|
|
|
|
|
|
In article <CMq1Jp.CAy@eecs.nwu.edu> hpa@ahab.eecs.nwu.edu (H. Peter Anvin N9ITP) writes:
|
|
|
|
In article <2m25ee$iv4@cville-srv.wam.umd.edu> of comp.os.linux.development,
|
|
barspi@wam.umd.edu (Barzilai Spinak) writes:
|
|
> After 1 1/2 years of waiting, I will shortly have a BIG computer and
|
|
> will install Unixware, Linux and Windows (ugh! ...I need to). My question
|
|
> is if there's a Unixware filesystem the Linux can use. I don't know anything
|
|
> about Unixware yet and I don't know if it uses a proprietary filesystem
|
|
> or not.
|
|
|
|
Unixware probably uses either UFS or the SysV filesystem. Linux
|
|
supports the SysV filesystem; it does not support UFS.
|
|
|
|
Unixware, by default, uses the Veritas filesystem, which is a
|
|
log-structured filesystem with extremely good crash recovery. I have
|
|
only once ever seen a veritas filesystem come up so much as dirty
|
|
after a crash, and that once, a simple fsck didn't even have to do any
|
|
corrections to the filesystem -- just marked it clean. And I have
|
|
seen plenty of hard crashes on unixware machines running veritas --
|
|
device driver development...
|
|
|
|
Unixware does also support other filesystems, including UFS and SysV,
|
|
but the SysV filesystem it supports *is* limited to 14 character
|
|
filenames, (of course), and so is of limited use. As Peter pointed
|
|
out, it's the only filesystem in common, though.
|
|
|
|
michaelkjohnson
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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
|
|
******************************
|