[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GEMDOS re-entrancy
Evan K. Langlois writes:
> ========================================================================
> but this does not mean you cannot sleep for disk IO, like it also
> doesn't mean my editor has to waste CPU time polling the tty for the
> ========================================================================
>
> Disk IO seems like it may be difficult, but certainly possible. I don't
> think yor editor should poll for IO at all.
oops :) what i was trying to say is my editor does of course not poll...
and if it works for tty IO then why should it be impossible for DMA disk IO.
> If you have an editor that
> is doing this, throw it away!! And editor doesn't need to do anything
> but wait for a keypress, so it should use blocking IO, even under normal
> TOS.
(well on vanilla TOS you still need to poll to distinguish ESC
sequences from a single ESC etc. because there is no alarm(), but
anyway...)
> My terminal uses blocking IO by using tfork() to handle input and
> output as separate threads.
btw which one is that? might interest miff to get cu running... :)
>
> ========================================================================
> sure if you don't want to port a real BSDfs, linux ext2 or something
> instead... i.e. why not make something _better_ than V2? :)
> ========================================================================
>
> I have the source to HPFS filesystem used by OS/2. Anyone want it? It
> doesn't look like it would be TOO difficult to port. Its kinda half DOS
> with a Minix internal or something.
yes, half-DOS (with some BSD internals)... is that the one that doesn't
even have real file modes? i would rather take the real thing!
> There are some things that would have
> to be changed though, for example, OS/2 allows you to set the file size when
> you open/create a file - that way the filesystem can allocate exactly enough
> space for it without fragmenting the disk,
well BSDfs mostly takes care of fragmentation problems itself...
hmm :) anyone would like to read this? (~20K gzip'd...)
A Fast File System for UNIX*
Marshall Kirk McKusick, William N. Joy|-,
Samuel J. Leffler|=, Robert S. Fabry
Computer Systems Research Group
Computer Science Division
Department of Electrical Engineering and Computer Science
University of California, Berkeley
Berkeley, CA 94720
ABSTRACT
A reimplementation of the UNIX file system is
described. The reimplementation provides substan-
tially higher throughput rates by using more flex-
ible allocation policies that allow better local-
ity of reference and can be adapted to a wide
range of peripheral and processor characteristics.
The new file system clusters data that is sequen-
tially accessed and provides two block sizes to
allow fast access to large files while not wasting
large amounts of space for small files. File
access rates of up to ten times faster than the
traditional UNIX file system are experienced.
Long needed enhancements to the programmers'
interface are discussed. These include a mechan-
ism to place advisory locks on files, extensions
of the name space across file systems, the ability
to use long file names, and provisions for admin-
istrative control of resource usage.
Revised February 18, 1984
_________________________
* UNIX is a trademark of Bell Laboratories.
|- William N. Joy is currently employed by: Sun
Microsystems, Inc, 2550 Garcia Avenue, Mountain View,
CA 94043
|= Samuel J. Leffler is currently employed by:
Lucasfilm Ltd., PO Box 2009, San Rafael, CA 94912
This work was done under grants from the National
Science Foundation under grant MCS80-05144, and the
Defense Advance Research Projects Agency (DoD) under
ARPA Order No. 4031 monitored by Naval Electronic
System Command under Contract No. N00039-82-C-0235.
...
> and it would really help with
> filesystems like ramfs .. which needs to reallocate RAM constantly.
and for ramfs, couldn't you just lseek (size) and write something
when this is a problem?
> ========================================================================
> hmm Tgetdate/time is called quite often, MiNT should better keep the
> time itself...
> ========================================================================
>
> Keep time? How? Through the system tick? Isn't it easier to jst read
> the time from the keyboard clock? I would think that would be more
> accurate. Does this slow down MiNT?
AFAIK GEMDOS uses the etv_timer interrupt itself... reading the IKBD
clock every time would be slow because it essentially does a blocking
ACIA write and read for a few bytes @ 7800 bps. is the IKBD's clock
more accurate than the 2.4576 MHz the 200 Hz timer is clocked from?
then maybe synchronize every x minutes... or leave that to the user
who might have something even more accurate? (DCF77, ntp... :)
>
> ========================================================================
> > As for DMA hard disk IO having problems with the BLiTTER,
> > isn't there a semaphore for this? Yeah, here it is, flock @ 0x0000043E.W
>
> is that used for `real' SCSI IO (TT) and IDE too?
> ========================================================================
>
> The entry for it just says to set that value to non-zero prior to accessing
> the DMA registers to prevent the system or other processes from accessing
> DMA concurrently.
OK for ACSI/FDC, but is this set for the TT's SCSI port for and IDE
disks too? anyone knows??
> ========================================================================
> ACSI/FDC is a bit on the ST 68881... (i'd have to look it up but i guess
> claus knows these already :)
> ========================================================================
>
> Nope, thats the FPU and most STs don't have one. Would be the MFP.
yup 68901, remembered the wrong number...
> #5 I think.
> ========================================================================
> not more than ACSI disk if you write a new floppy driver. except
> that it'll block its channel a bit longer probably, given floppies
> access time and data rate... :)
> ========================================================================
>
> Hmm .. lessee that's 11K/second. So, we might be able to pass the
> test the Intel users thought up? The way they test for REAL multitasking
> is being able to format a floppy in the background :-)
>
hmm actually i've done that already, answered some mail on ttyv2 while
pumpup.prg was running on console... :) its just there are not many
cycles left now with all the blocking/polling going on.
cheers
Juergen
--
J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
...ohne Gewehr
PGP public key fingerprint = 8A 18 58 54 03 7B FC 12 1F 8B 63 C7 19 27 CF DA