Re: kern/41189: kernel panic xen dom0 using mke2fs & WAPBL

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/41189; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/41189: kernel panic xen dom0 using mke2fs & WAPBL
Date: Sun, 13 Sep 2009 18:37:07 +0000

 On Sat, May 09, 2009 at 07:35:01AM +0000, Andrew Doran wrote:
  >>> I disagree. I think the solution is:
  >>> 
  >>> - devfs
  >>> - kill block devices in userspace
  >>> - allow unaligned I/O to disk devices via the raw node
  >> 
  >> How/why? As I've already explained once (mostly quoted above), devfs
  >> will not solve the real problem, just move it around. What are you
  >> envisioning that devfs will provide that will avoid the confusion?
  >> [...]
  >> Please *explain* your reasoning.
  >  
  >  I should have been clearer. Have a look at the bigger picture.
 
 Thank you, but four months later I still don't understand.
 
  >  - We have longstanding problems with device nodes showing up in
  >    multiple file systems. For 6.0 we have devfs coming along, which
  >    will at some point in its development likely eliminate the need
  >    to support device nodes on other file systems. So devfs will
  >    give us a 1:1 mapping between device instances and vnodes (or
  >    maybe devfs inodes).
 
 More likely the latter, but even assuming all this happens, it won't
 solve the problem. We'll end up with devfs ops being called on
 arbitrary non-devfs vnodes, same as the previous round of problems
 gave us wapbl ops being called on arbitrary non-wapbl vnodes, and
 before that we had softupdate ops being called on non-softupdate
 vnodes, and so on ad infinitum.
 
 The problem is that as things stand, the device vnode half belongs to
 the FS it came from and half to the FS that's mounted on it. The
 dividing line isn't clear (I'm not entirely convinced it's even well
 defined) and therefore it's easy for mistakes to arise. When mistakes
 arise, the consequence is often calling the wrong vnode ops. There are
 probably cases where the consequence is more subtle than that, too.
 
 This is a structural problem, and to really make it go away for real
 it needs to be solved structurally.
 
 The device vnode should belong only to the FS it came from, whether
 that's devfs or wapbl or whatever.
 
  >  - We have longstanding problems providing block device semantics. Block
  >    devices are an interesting toy but they have no real application. Disk
  >    character devices suffice with one exception: on NetBSD, transfers on
  >    these devices must be aligned. So there is no need for physio to cache,
  >    it could simply buffer to allow misaligned transfers.
 
 This I have no disagreement with; it's just not relevant to what I'm
 concerned about.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost