🚀 go-pugleaf

In article <1990Aug27.223445.4474@sco.COM> seanf@sco.COM (Sean Fagan) writes:
> In article <11576:Aug2503:18:3790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >Say a program computes some numbers. Computes them optimally, in fact,
> >leaving them in an array. Now it wants to write the array to disk.
> >If the operating system weren't in the way, the program would simply
> >call upon the disk device to copy the data---through DMA, of course---to
> >the disk.
> Uhm, *where* is it going to put it?
> Or does the user program just automagically know which sectors on the disk
> are free to write in, and, of course, it's going to up date the inode
> information properly, and all directory information.

Who cares? It can use any disk management scheme it likes. This is
absolutely irrelevant to the issue: the time to update, say, the inodes
is at most a fraction of the time it takes to copy a large block of data
from one place in memory to another.

> Having worked on an OS that does to asynchronous I/O quite well (NOS, for
> those who don't read comp.arch 8-)), it's a bit different from what brnstnd
> says.

I was describing how asynchronous I/O works when there's no OS in the
way. You start talking about how a particular OS does asynchronous I/O.
``It's a bit different''---``No shit, Sherlock!'' RTFABYFU.

---Dan