dieter roelants dieter.net...@pandora.be wrote:
On an amd64 kernel with DIAGNOSTIC and LOCK_DEBUG enabled, the
following assertion got triggered while building packages:
anon-an_lock == amap-am_lock in sys/uvm/uvm_fault.c line 1228
I think hannken@ and yamt@ fixed the bugs here. Please try.
On Sat, 25 Jun 2011, der Mouse wrote:
That what it is reasonable for a disk to do consensus *is* the
interface spec I was talking about, not the de-jure non-spec of you
get whatever the device (via its driver) feels like giving you.
That's sort of the point. If you want what it is reasonable
That what it is reasonable for a disk to do consensus *is* the
interface spec I was talking about, not the de-jure non-spec of you
get whatever the device (via its driver) feels like giving you.
That's sort of the point. If you want what it is reasonable for a
disk to do you should be using
On Sat, Jun 25, 2011 at 09:29:57PM +0700, Robert Elz wrote:
| At least for NetBSD, that's never been true. The most glaring
| problem is that there's no protection against causing the same
| underlying disk blocks to be multiply cached by accessing the
| buffer cache with a different
On Sat, Jun 25, 2011 at 08:57:30PM +0200, Johnny Billquist wrote:
I might be confused here. I thought that if you accessed the block
device, you were restricted to blocks. So you can in fact not seek
to an arbitrary byte, nor read an arbitrary length, like for a
normal file, but instead
On Jun 27, 2011, at 10:59 , David Holland wrote:
On Sat, Jun 25, 2011 at 08:57:30PM +0200, Johnny Billquist wrote:
I might be confused here. I thought that if you accessed the block
device, you were restricted to blocks. So you can in fact not seek
to an arbitrary byte, nor read an arbitrary
On 27 Jun 2011, at 10:27 , der Mouse wrote:
That what it is reasonable for a disk to do consensus *is* the
interface spec I was talking about, not the de-jure non-spec of you
get whatever the device (via its driver) feels like giving you.
That's sort of the point. If you want what it is
We're all dancing around a very fundamental question here: what interface
abstraction should the raw interface to a disk controller (and attached
disks) present?
We're not going to allow userland to directly write device registers as a
general practice (X11 notwithstanding, and that's a
On Jun 27, 2011, at 1:55 PM, David Holland wrote:
...
It took the invention of that paragon of OS's - DOS - to teach
the populace that simply pulling the device/media was an acceptable
operating procedure.
That's hardly fair. Until the Mac appeared in 1984 every small
computer that had
On 06/27/11 21:02, Dennis Ferguson wrote:
On 27 Jun 2011, at 10:27 , der Mouse wrote:
That what it is reasonable for a disk to do consensus *is* the
interface spec I was talking about, not the de-jure non-spec of you
get whatever the device (via its driver) feels like giving you.
That's
On Jun 25, 2011, at 11:57 , Johnny Billquist wrote:
True. However, Unix have never really gracefully handled file systems or
devices that comes and goes. :-)
As Robert Elz wrote (and I'll echo): UNIX has always handled removable devices
- you just have to tell UNIX that you're going to
11 matches
Mail list logo
