Re: parsepath op

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

On Sun, Jan 02, 2011 at 10:48:03AM +0000, David Laight wrote:
 > On Sun, Jan 02, 2011 at 09:17:11AM +0000, David Holland wrote:
 > > Because we have at least one FS that may not want paths being looked
 > > up to be split on '/', namely rump etfs, and arguably the most
 > > important simplification to VOP_LOOKUP is to make it handle one path
 > > component at a time, we need a way for a FS to decide how much of a
 > > path it wants to digest at once.
 > 
 > Slightly related is something I did for an embedded os, where
 > I appended /param1/param2 to a device path.
 > [...]

Right, I think the original art for this came from AmigaDOS. It's
always seemed like a useful idiom to me (much better than creating a
dozen variant device nodes for every physical device) and I don't
intend to do anything that will rule it out.

Basically to make it work we'd need to patch namei to allow calling
VOP_LOOKUP on device nodes instead of giving ENOTDIR, and add a
spec_lookup implementation that does some kind of string-to-ioctl
mapping to issue state changes on the device vnode. Currently writing
a VOP_LOOKUP implementation is a black art, but that's supposed to
change, and I don't think this would require any other special hacks.

-- 
David A. Holland
dholland%netbsd.org@localhost