On Wed, Sep 26, 2007 at 02:29:30PM +0200, Kay Sievers wrote:
> I really don't want to see something like: "the user isn't asking for
> information which isn't in the blkid cache" thing near the code udev
> has to call. The cache must be part of the "high-level" blkid
> functions, and nothing like this should come near the plain probing
> functions.
> The compile-time udev switch and the udev symlink logic is already in
> the util-linux fsprobe wrapper, and there is no need to move that
> into blkid now, especially not by trying to make anything
> "transparent".
I expect description of filesystem + probing function + FS magic
strings and two interfaces:
1) a low-level interface where we will "blindly" call probing
function(s) and
2) a high-level interface with "smart" features like cache,
/dev/disk/by-* support, device-mapper support, etc.
A description of filesystem should be stored in the same file like a
probing function. I think better is one .c file per filesystem (like
in udev). For example:
util-linux-ng/libfsprobe/fs/swap.c:
static int
probe_swap(struct probe *p, struct fsmagic *m)
{
if (strcmp(m->magic, "SWAP-SPACE")==0)
fsprobe_set_tag(p, "VERSION" "1");
else if (strcmp(m->magic, "SWAPSPACE2")==0)
fsprobe_set_tag(p, "VERSION", "2");
else
return -1;
if (! (p->flags & (LABEL|UUID))
/* don't waste time, LABEL/UUID unnecessary */
return 1;
buf = fsprobe_get_buff(p->dev, 10);
.....
fsprobe_set_tag(p, "LABEL", foo);
fsprobe_set_tag(p, "RAWLABEL", foo);
fsprobe_set_tag(p. "UUID", bar);
}
static struct fsmagic swap_magics[] = {
/* offset, len, magic */
{ 0xff6, 10, "SWAP-SPACE" },
{ 0xff6, 10, "SWAPSPACE2" },
{ 0, 0, NULL }
};
struct fsdesc swap_desc = {
.name = "swap";
.probe_fn = probe_swap;
.magic = swap_magics;
.family = FSP_OTHER; /* or _RAID, _FILESYSTEM, _CRYPT, ... */
.flag = FSP_MAGIC_REQUIRED;
};
util-linux-ng/libfsprobe/probe-low.c
...
util-linux-ng/libfsprobe/probe-high.c
...
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
