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  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]
Date:   Wed, 12 Aug 2020 15:39:57 +0100
From:   Al Viro <>
To:     Miklos Szeredi <>
Cc:     Linus Torvalds <>,
        Jann Horn <>,
        Casey Schaufler <>,
        Andy Lutomirski <>,
        linux-fsdevel <>,
        David Howells <>,
        Karel Zak <>, Jeff Layton <>,
        Miklos Szeredi <>,
        Nicolas Dichtel <>,
        Christian Brauner <>,
        Lennart Poettering <>,
        Linux API <>,
        Ian Kent <>,
        LSM <>,
        Linux Kernel Mailing List <>
Subject: Re: file metadata via fs API (was: [GIT PULL] Filesystem Information)

On Wed, Aug 12, 2020 at 09:23:23AM +0200, Miklos Szeredi wrote:

> Anyway, starting with just introducing the alt namespace without
> unification seems to be a good first step. If that turns out to be
> workable, we can revisit unification later.

Start with coming up with answers to the questions on semantics
upthread.  To spare you the joy of digging through the branches
of that thread, how's that for starters?

"Can those suckers be passed to as starting points?  Can they be bound in namespace?
Can something be bound *on* them?  What do they have for inodes
and what maintains their inumbers (and st_dev, while we are at
it)?  Can _they_ have secondaries like that (sensu Swift)?
Is that a flat space, or can they be directories?"

Powered by blists - more mailing lists