I think you forgot something......: MS-Windows isn't an Operating System in
the purist sense. Command.com will let you block disk access for a time
(that is how the old NDD 7.0 and Speedisk (4.0?) used to work under DOS
without getting "interrupted" by a disk write), but kernel.exe and thus
kernel32.exe are "simulated multiprocessing" handlers, and thus you cannot
(currently.., the people at MS are working on this) properly "lock out"
access to a disk (or anything else for that matter) unless you are talking
specifically about the "critical time" for each Win32 executable (which are
all modules of kernel(32?).exe)--which is locked out to prevent massive
horrid errors in any form of execution that may take place on the machine.
Drew Northup, N1XIM
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Kenneth Arnold
> Sent: Wednesday, September 20, 2000 12:15 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Thoughts. (multi processor)
>
>
> On Tue, Sep 19, 2000 at 07:49:51PM -0400, Drew Northup wrote:
> > Great thought..., but once again Intel has broken it before you
> could even
> > try. The main problem with the multiprocessor argument is not just the
> > ring0 code (which is a real pain) it is also that SMP was
> designed with the
> > intention that you never know what process is running on which
> processor,
> > and thus the user level stuff doesn't know any "better" as to what it is
> > really doing at the hardware level. OH well, maybe later.......;^)
> >
> > As for using a hard drive instead of a file, you have one MAJOR and
> > undeniable sticking point.....partition tables & hard drive access
> > permissions. In LINUX and other UNIX-like systems, you must
> mount a drive
> > manually. However, in many, many other systems, a hard drive
> partitions of
> > a matching type are AUTOMATICALLY mounted on boot. Thus you'd have two
> > systems writing to a filesystem that they can both see AT THE "HARDWARE"
> > LEVEL and there is no host, no master, no "in charge" system controlling
> > disk access. This leads to unbelievable data loss and other
> catastrophic
> > problems. If you'd like proof of this, set up a joint scsi bus
> between two
> > machines, format a partition on a drive as something that they can both
> > access as something that they can both access, and then make
> sure that they
> > can both mount the partition. Then try to write to the drive from both
> > machines simultaneously. The drive will become unrecoverably corrupted.
> > Granted, we wouldn't be trying to do exactly the same thing, but I think
> > that I made my point that the logistics of the issue of RAW
> disk access by
> > the guest are just way beyond what we would even want to
> consider right now.
>
> So you do like dosemu and "strongly suggest" unmounting the drive
> first. Or,
> if you're really keen at hacking code, write a filesystem access
> layer. Sounds
> quite a bit too hard to work on right now, though. As for the
> other systems,
> there is usually some kind of locking mechanism to at least
> prevent fsck-type
> utilities from mucking around with it at the same time (which
> would be the only
> real cause of concern if you find a way to tell the OS to keep its buffers
> flushed) -- I'm thinking Windows here; Norton Disk Doctor somehow
> puts a "lock"
> on the drive and Speed Disk complains about that. Considering how
> much other
> stuff you can muck around with in Windows, I wouldn't be at all
> suprised to
> find a way to do all fs ops async, disable all disk caching,
> and/or totally
> block access to a partition for a certain length of time. Of course there
> will always be the user who thinks that they can run Linux under
> Linux using
> raw access to the same partition... oops.
>
> Kenneth
>
