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=-5.3 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 E162AC47423 for ; Fri, 2 Oct 2020 11:30:55 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 12CF3206DC for ; Fri, 2 Oct 2020 11:30:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AFa5prIa" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 12CF3206DC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94) (envelope-from ) id 1kOJGj-0005FM-S4; Fri, 02 Oct 2020 07:30:33 -0400 Received: from mail-pf1-x443.google.com ([2607:f8b0:4864:20::443]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kOJGg-0005FH-Mm for kernelnewbies@kernelnewbies.org; Fri, 02 Oct 2020 07:30:30 -0400 Received: by mail-pf1-x443.google.com with SMTP id 144so1038133pfb.4 for ; Fri, 02 Oct 2020 04:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/OcPogznsOChSL1wDk+F/dtQIgUJJO02qu0oBoVHbmU=; b=AFa5prIa45UVewAsntl1B0Ulp3WCUZJ7x8lge2V0r4ZzQuvHLmre9P5jlCIbcphf/G 6x5jZSPBdKCabpqKuWxbgHVo0Sk66FaY9UkloTf6x1+mCH7dqC2dFTfj6fSHqscLe1yi 6oSBurYHTlcN7TgQMvHoRiw8KQLtkD8CCQ9pVfWvJbLopP/HJcEkBKsHm5WzSKz6nc/g T9ophNgqQWF1GpyEJeXRcmPFpP7aNCPOXwes7EWmEj//gIGqwXGAJhc0kgHuUS0wJ2LK fpdcu01FQJO8XcNd7njLuNywy4pfiAWMyq60/Z5hVTUSRRee72x0imigL5pUJw3wXfEN zlig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/OcPogznsOChSL1wDk+F/dtQIgUJJO02qu0oBoVHbmU=; b=HUN+rmEX7X0+kl9dDwiikbsiq3GKfQYxaiBmEtHHvplXWMHDMv6mEmt86bnhXqy/XT 2aPH8M1U2BqBkmCcGXawDNfZ3d+zT9CeMPTfdDUgIZ/0bzmNf4e2su2VjTZfTHqQR113 3DOgr/hh3bK9UF+tF9lOsTaoLG6lSKK7YM+UKUjPwuhmr/2qAdEsTpOB2Jp7rxQ5QEps djs2T+9d18vlxGvMsfEoqWZT91nCkG6R5UUB/7JEo5kR1UtcUEMK125eTc2mbvCuroee 2COIci+Jqwa5ohNZroowoIkUp+TIdZ6x4ifsG1az7VPIRTmVWbJZ7rX23X3HDNQ/d8SI N1PA== X-Gm-Message-State: AOAM531mr/6qr0XlwAEKcM2rC6R39m06GAqubSErTG2+AfIi+ZqStPw1 pAl/ClKWdru5RDa/QBHOwzc+lxzZMew= X-Google-Smtp-Source: ABdhPJwWHQyUX82p1CszZ9V5qvtgU4xMGEZ+Ur4xmkUDfY8ceKMhDtlJz7aIAKRQj/p7tSwRqYPyFw== X-Received: by 2002:a05:6a00:2db:b029:142:2501:34ed with SMTP id b27-20020a056a0002dbb0290142250134edmr2150628pft.70.1601638167685; Fri, 02 Oct 2020 04:29:27 -0700 (PDT) Received: from [10.149.182.253] ([49.205.253.183]) by smtp.gmail.com with ESMTPSA id 134sm1673310pfa.93.2020.10.02.04.29.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Oct 2020 04:29:26 -0700 (PDT) Subject: Re: Accessing allocated space in a debugfs file To: Greg KH References: <20200930174906.GA1687038@kroah.com> From: ymdatta Message-ID: <1e7b7d6d-0764-01fc-e527-f2e703e45ca2@gmail.com> Date: Fri, 2 Oct 2020 16:59:24 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200930174906.GA1687038@kroah.com> Content-Language: en-US Cc: kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org On 30/09/20 11:19 pm, Greg KH wrote: > On Wed, Sep 30, 2020 at 10:32:05PM +0530, ymdatta wrote: >> >> I want to write in this file, how should i be accessing the space created >> from previous function call. > > That's not what "size" means here. "size" just sets the value that you > see if you look at the directory for that debugfs file (or stat() it). > Didn't realize this. Why do we need this then? What does this 'size' help in achieving (or) where is this used? > debugfs is a virtual filesystem, there is no "backing store" or place to > put your data in it. It is there so that you can write code that can > handle open/read/write/close to happen on a file, and your code will > provide the data to userspace directly. > > The simplest way to create a debugfs file is to just point it at a > variable, and then you can change the variable value in the kernel, and > userspace reading from the file will see whatever the value is at that > point in time. This clears up a lot of my doubts. Thanks! ymdatta. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies