On Tue, 2007-09-25 at 11:14 +0200, Karel Zak wrote: > On Mon, Sep 24, 2007 at 08:40:36AM -0400, Theodore Tso wrote: > > On Mon, Sep 24, 2007 at 11:25:39AM +0200, Karel Zak wrote: > > > > > > > > Nope, there isn't much rationale unless we also split out fsck, so > > > > > > util-linux-ng is open for fsck :-) > > > > It's something I'm considering, but at the moment I've got some higher > > priority (ext4) work that I'm focusing on. > > That's nothing urgent. This migration shouldn't be so difficult -- I > think we should provide at least one release when the util is in both > packages -- defaultly disabled in e2fsprogs and enabled in > util-linux-ng. It's probably better that trying to synchronize > releases of both packages. > > > What would you think about moving libblkid and the libdisk from > > xfsprogs into util-linux-ng? That's things that I've been batting > > I have no problem with this idea, but I'd like to invite Kay Sievers > (udev) to this discussion. I think the best step will be merge > libblkid and libvolume_id to the one independent project. Oh, I would be fine with putting that in util-linux. Mount is the most critical user, so it has it's place there from my point of view. And having mount and fsck in util-linux, sharing the fsprobing code and fstab-parsing code sounds great to me. > There is > few technical problems with this idea, but nothing insolvable. I'm all for doing this, and don't see any real problem with that. I talked to Ted a few weeks ago when we met in person about this already. > Now we duplicate a lot of FS probe code in libblkid, libvolume_id and > libdisk. > > Yes, it's long-term task, but it's good direction (IMHO). It is, and we are not providing a real value to the users by providing both of these libs at the same time. :) But udev has a very different requirement for probing filesystems. Unlike non-udev systems, we can't accept any hidden policy inside a library. We just want to pass a byte stream to the lib, and get back what exactly is in _this_ byte stream. There must be no chaching, no devmapper logic, no stat()'ing in /dev, no reading of /proc/partitions, no ioctl()'s, no hidden decisions, nothing. None of these actions is acceptable to be done by the library itself, if udev is used. We need pure mechanics, no policy. We also need an API that allows to specify the size of the stream and the probing offset. And we don't want to iterate over tags, need the filesystem version information, the raid metadata probing, and the classification volume_id provides. That means that we could replace the "low-level" part of libblkid with volume_id code, and keep the current API of blkid, but offer some of the low-level functionality for udev. Or we would implement the relevant parts and probers in blkid, and add a new API to access the low-level part directly. Note, that even with only one fsprobing library, util-linux would still need to behave differently on a udev system, because we can't afford to maintain a cache file, or search for anything else at event time, on systems with 20.000 hard disks connected. But systems without udev will obviously need the "search all devices" functionality of blkid to find labels and uuid's. Let me know what you think how go ahead with this, I'm all for doing this sooner than later. Cheers, Kay - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
