Thread (4 messages) 4 messages, 4 authors, 2007-09-25

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]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help