Re: [PATCH] obsolete libcom-err for SuSE e2fsprogs
From: Karel Zak <kzak@redhat.com>
Date: 2007-09-25 12:34:58
On Tue, Sep 25, 2007 at 12:11:23PM +0200, Kay Sievers wrote:
On Tue, 2007-09-25 at 11:14 +0200, Karel Zak wrote:quoted
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.
Technical details :-)
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.
I don't see a problem to provide low-level and high-level interface in same library. The low-level stuff (fsprobe code) is still same. Things like a cache are discussable -- for example resolve LABEL/UUID on system with udev is faster by /dev/disk/by-*. I think a good library has to be smart enough to found the fastest way how translate LABEL/UUID to device name. But, it's too early to talk about details.
Let me know what you think how go ahead with this, I'm all for doing this sooner than later.
Cool. I'd like to create libfsprobe as an independent project. Or is
there any advantage to merge everything to util-linux-ng? I don't
think so.
Karel
--
Karel Zak [off-list ref]