Hello, Ted. On Fri, Jan 14, 2011 at 6:59 PM, Ted Ts'o <tytso@xxxxxxx> wrote: > Yes, agreed. My point was that if we have a better system, we could > migrate blkid and other users to new interface, and maybe in a few > years, we can deprecate that interface. So we do have to maintain > them for at least the medium term, but that shouldn't stop us from > divising a better interface, and then gradually migrating systems to > use that newer and better interface. Oh yeah, fully agreed there and the implementation at the block layer isn't even gonna be difficult. Just a single attribute which contains a string which can be specified at the time of claiming. We probably can introduce a new interface where the @holder is always a string the content of which should uniquely identify the holder in human/machine readable form and add a few helpers to format those strings so that the same type of usages use consistently formatted strings. For nested devices, kdev should do. For filesystems, the mount point maybe (it should be something which identifies it absolutely)? For specific programs (cd burner, whatnot), pid and so on. The only question is, would that be actually necessary? By now, we already have mostly working reverse mapping for most things which matter through blkid, fs information, fd listing under proc and so on. They sure are ugly and probably unreliable at times but is it pressing enough to introduce new interface and migrate things over or would we be just creating churns? I don't really know how these things look from userland so am genuinely unsure what the answer is. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
