From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 25262C4320A for ; Sun, 8 Aug 2021 05:15:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0550261004 for ; Sun, 8 Aug 2021 05:15:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229516AbhHHFPW (ORCPT ); Sun, 8 Aug 2021 01:15:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:36878 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229473AbhHHFPV (ORCPT ); Sun, 8 Aug 2021 01:15:21 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BD2ED60F38; Sun, 8 Aug 2021 05:15:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1628399703; bh=r409KvyNgLbyfYI1tePdR3Fn6jngjHs4GuZ52QDGYW0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BXaZWx+jEEFDknjNvDH/ZpiTRbEA+YwNxqFY6NSHsrrXBX26RK2hiL6lej1aHNrBm U/tyz+1uA3ldYaa5lHZ945pr1Anh+tqG/mGG0hdP156kvDb0CQjPjQlxOcOB6LD6Sv Ogm4uQtfoY8H9qTf40aoJS4CD0PpeCVeZdzY8Kls= Date: Sun, 8 Aug 2021 07:14:52 +0200 From: Greg Kroah-Hartman To: Long Li Cc: Bart Van Assche , "longli@linuxonhyperv.com" , "linux-block@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , Jonathan Corbet , KY Srinivasan , Haiyang Zhang , Stephen Hemminger , Wei Liu , Dexuan Cui , Bjorn Andersson , Hans de Goede , "Williams, Dan J" , Maximilian Luz , Mike Rapoport , Ben Widawsky , Jiri Slaby , Andra Paraschiv , Siddharth Gupta , Hannes Reinecke Subject: Re: [Patch v5 0/3] Introduce a driver to support host accelerated access to Microsoft Azure Blob for Azure VM Message-ID: References: <1628146812-29798-1-git-send-email-longli@linuxonhyperv.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-hyperv@vger.kernel.org On Sat, Aug 07, 2021 at 06:29:06PM +0000, Long Li wrote: > > I still think this "model" is totally broken and wrong overall. Again, you are > > creating a custom "block" layer with a character device, forcing all userspace > > programs to use a custom library (where is it at?) just to get their data. > > The Azure Blob library (with source code) is available in the following languages: > Java: https://github.com/Azure/azure-sdk-for-java/tree/main/sdk/storage/azure-storage-blob > JavaScript: https://github.com/Azure/azure-sdk-for-js/tree/main/sdk/storage/storage-blob > Python: https://github.com/Azure/azure-sdk-for-python/tree/main/sdk/storage/azure-storage-blob > Go: https://github.com/Azure/azure-storage-blob-go > .NET: https://github.com/Azure/azure-sdk-for-net/tree/main/sdk/storage/Azure.Storage.Blobs > PHP: https://github.com/Azure/azure-storage-php/tree/master/azure-storage-blob > Ruby: https://github.com/azure/azure-storage-ruby/tree/master/blob > C++: https://github.com/Azure/azure-sdk-for-cpp/tree/main/sdk/storage#azure-storage-client-library-for-c And why wasn't this linked to in the changelog here? In looking at the C code above, where is the interaction with this Linux driver? I can't seem to find it... > > There's a reason the POSIX model is there, why are you all ignoring it? > > The Azure Blob APIs are not designed to be POSIX compatible. This driver is used > to accelerate Blob access for a Blob client running in an Azure VM. It doesn't attempt > to modify the Blob APIs. Changing the Blob APIs will break the existing Blob clients. There are no Blob clients today on Linux given that this code is not merged into the kernel yet, so there is nothing to "break". I still don't see a good reason why this can't just be a block device, or a filesystem interface and why you need to make this a custom character device ioctl. thanks, greg k-h