Re: [PATCH] obsolete libcom-err for SuSE e2fsprogs

[Kay Sievers <kay.sievers-tD+1rO4QERM@public.gmane.org>]

On Tue, 2007-09-25 at 14:34 +0200, Karel Zak wrote:
> 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:
> > >  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 :-)

What do you miss, these are all technical details. :) In simple words,
we need a completely policy-free, not try-to-be-smart in any sense set
of functions to identify a bytestream by magic bytes.

> > 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.

Yes, it would be the 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.

This is exactly what I mean and need to avoid. The library should not
try to be smart if not explicitly asked for. It should definitely not
"try to find something out". The caller is smart enough in this case.

>  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.

Hmm, only if you reaqlly don't want to pull it in util-linux, we could
have it as a separate tree. I still think util-linux is the best place,
because the most important user of it is mount/fsck. It's your call, I
would have no problem sending patches against util-linux. :)

Kay