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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070925152032.GB2807@thunk.org>
Date:	Tue, 25 Sep 2007 11:20:32 -0400
From:	Theodore Tso <tytso@....edu>
To:	Karel Zak <kzak@...hat.com>
Cc:	Kay Sievers <kay.sievers@...y.org>,
	Eric Sandeen <sandeen@...hat.com>,
	Andreas Dilger <adilger@...sterfs.com>,
	linux-ext4@...r.kernel.org,
	List util-linux-ng <util-linux-ng@...r.kernel.org>
Subject: Re: [PATCH] obsolete libcom-err for SuSE e2fsprogs

On Tue, Sep 25, 2007 at 02:34:54PM +0200, Karel Zak wrote:
> > 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.

Agreed, one interface and one code base for determining "what is this
filesystem is a good thing".

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

It depends on what you're doing, actually.  If you want to resolve
multiple UUID's, it will be faster to use the cache, since it's in
memory.  And the blkid cache will allow you to do things like find all
devices with a particular filesystem type, etc.  And although blkid
doesn't do this now, it's a more flexible model for handling things
like "to find the ext3 journal with UUID=XXXX-...-XXXX", use this
iSCSI device at this IP address.  Assuming that you can always probe
all 30,000 devices and populate /dev/disk/by-* at boot time is not
necessarily something that I would consider scalable; if you have
hundreds of thousands of LUN's connected to a storage array that
aren't mounted at boot time, and only mounted on demand when a
particular LUN is needed, I think the udev model doesn't fit all that
well.

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

My main concern is avoiding what the "GNOME library problem".  Huge
numbers of independent projects makes build dependencies incredibly
painful.  And of course, any time we do this kind of factoring we need
to keep the interfaces stable.  In userspace, with published, stable
API's are not nonsense, but an absolute and unconditional requirement.

     	      		       		    		  - Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html