Re: [git pull] new mount API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Aug 23, 2018, at 5:31 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> 
>> On Thu, Aug 23, 2018 at 05:16:53PM -0700, Andy Lutomirski wrote:
>>> On Thu, Aug 23, 2018 at 5:08 PM, David Howells <dhowells@xxxxxxxxxx> wrote:
>>> Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>>> 
>>>> Has anything been done to ensure that the behavior when doing
>>>> FSCONFIG_CMD_CREATE against an already-mounted block device is
>>>> reasonable?
>>> 
>>> For the moment, I've left it as the same behaviour as for mount(2) since
>>> mount(2) now uses the same mechanism internally and we aren't permitted to
>>> break userspace.
>>> 
>>> I would like to add at least one flag to stipulate that, in the case of an
>>> incompatible collision, you can get a failure - but defining what is meant by
>>> incompatible isn't necessarily trivial, and would vary by filesystem *and* the
>>> LSM.
>>> 
>>> However, I don't want to start reengineering everything this close to the
>>> merge window and we don't really need it immediately.
>>> 
>> 
>> The problem is that, once this ends up merged, then we're kind of
>> stuck with it, too.  It would be a bit sad if your better proposal for
>> handling nfs and instantiation of filesystems in general were added in
>> the next release and then we end up with the current
>> FSCONFIG_CMD_CREATE as a permanently supported but non-preferred
>> option.
> 
> For fuck sake, mount(2) is a permanently supported option!  

Exactly. mount(2) has broken semantics and it’s permanently supported.

If this merge request gets pulled, then FSCONFIG_CMD_CREATE will *also* be a permanently supported API with broken semantics.



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux