How do I implement a file system driver driver in Linux? [closed] Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) 2019 Community Moderator Election Results Why I closed the “Why is Kali so hard” questionHow does one install a camera driver from a c file, and what is this driver doing?what is the difference between Device driver and kernel moduledoes a user program always use system calls to access a device driverDevice files and drivers of a disk, partition, and filesystem?How to find the driver (module) associated with SATA device on Linux?Where does a device file come from?How is a wifi driver exposed to userspace?Locating kernel module from device node major, minor numberinteracting with kernel modules without giving users sudo access?How to check if a given driver kernel module supports a given device?

New Order #6: Easter Egg

Random body shuffle every night—can we still function?

Did any compiler fully use 80-bit floating point?

Does the universe have a fixed centre of mass?

Sally's older brother

Are there any irrational/transcendental numbers for which the distribution of decimal digits is not uniform?

newbie Q : How to read an output file in one command line

Is "ゲーム中に使用する" a descriptor in "ゲーム中に使用する最大HPを書き写す"?

Is this Half dragon Quaggoth Balanced

Determine whether an integer is a palindrome

Does the transliteration of 'Dravidian' exist in Hindu scripture? Does 'Dravida' refer to a Geographical area or an ethnic group?

malloc in main() or malloc in another function: allocating memory for a struct and its members

Does a random sequence of vectors span a Hilbert space?

Problem with display of presentation

Did John Wesley plagiarize Matthew Henry...?

Noise in Eigenvalues plot

Why weren't discrete x86 CPUs ever used in game hardware?

As a dual citizen, my US passport will expire one day after traveling to the US. Will this work?

How does the body cool itself in a stillsuit?

Should man-made satellites feature an intelligent inverted "cow catcher"?

Is the time—manner—place ordering of adverbials an oversimplification?

Why do C and C++ allow the expression (int) + 4?

Why did Bronn offer to be Tyrion Lannister's champion in trial by combat?

Is there a verb for listening stealthily?



How do I implement a file system driver driver in Linux? [closed]



Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)
2019 Community Moderator Election Results
Why I closed the “Why is Kali so hard” questionHow does one install a camera driver from a c file, and what is this driver doing?what is the difference between Device driver and kernel moduledoes a user program always use system calls to access a device driverDevice files and drivers of a disk, partition, and filesystem?How to find the driver (module) associated with SATA device on Linux?Where does a device file come from?How is a wifi driver exposed to userspace?Locating kernel module from device node major, minor numberinteracting with kernel modules without giving users sudo access?How to check if a given driver kernel module supports a given device?



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








14















Assume that I have invented a new file system, and now I want to create a file system driver for it.



How would I implement this file system driver, is this done using a kernel module?



And how can the file system driver access the hard disk, should the file system driver contain code to access the hard disk, or does Linux contain a device driver to access the hard disk that is used by all the file system drivers?










share|improve this question















closed as too broad by Gilles, muru, Michael Homer, jimmij, msp9011 Mar 25 at 10:47


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
























    14















    Assume that I have invented a new file system, and now I want to create a file system driver for it.



    How would I implement this file system driver, is this done using a kernel module?



    And how can the file system driver access the hard disk, should the file system driver contain code to access the hard disk, or does Linux contain a device driver to access the hard disk that is used by all the file system drivers?










    share|improve this question















    closed as too broad by Gilles, muru, Michael Homer, jimmij, msp9011 Mar 25 at 10:47


    Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.




















      14












      14








      14


      1






      Assume that I have invented a new file system, and now I want to create a file system driver for it.



      How would I implement this file system driver, is this done using a kernel module?



      And how can the file system driver access the hard disk, should the file system driver contain code to access the hard disk, or does Linux contain a device driver to access the hard disk that is used by all the file system drivers?










      share|improve this question
















      Assume that I have invented a new file system, and now I want to create a file system driver for it.



      How would I implement this file system driver, is this done using a kernel module?



      And how can the file system driver access the hard disk, should the file system driver contain code to access the hard disk, or does Linux contain a device driver to access the hard disk that is used by all the file system drivers?







      linux filesystems drivers






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Mar 24 at 23:07









      Gilles

      549k13111171631




      549k13111171631










      asked Mar 24 at 13:16









      user343344user343344

      763




      763




      closed as too broad by Gilles, muru, Michael Homer, jimmij, msp9011 Mar 25 at 10:47


      Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.









      closed as too broad by Gilles, muru, Michael Homer, jimmij, msp9011 Mar 25 at 10:47


      Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.






















          4 Answers
          4






          active

          oldest

          votes


















          23














          Yes, filesystems in Linux can be implemented as kernel modules. But there is also the FUSE (Filesystem in USErspace) interface, which can allow a regular user-space process to act as a filesystem driver. If you're prototyping a new filesystem, implementing it first using the FUSE interface could make the testing and development easier. Once you have the internals of the filesystem worked out in FUSE form, you might then start implementing a performance-optimized kernel module version of it.



          Here's some basic information on implementing a filesystem within kernel space. It's rather old (from 1996!), but that should at least give you a basic idea for the kind of things you'll need to do.



          If you choose to go to the FUSE route, here's libfuse, the reference implementation of the userspace side of the FUSE interface.



          Filesystem driver as a kernel module



          Basically, the initialization function of your filesystem driver module needs just to call a register_filesystem() function, and give it as a parameter a structure that includes a function pointer that identifies the function in your filesystem driver that will be used as the first step in identifying your filesystem type and mounting it. Nothing more happens at that stage.



          When a filesystem is being mounted, and either the filesystem type is specified to match your driver, or filesystem type auto-detection is being performed, the kernel's Virtual FileSystem (VFS for short) layer will call that function. It basically says "Here's a pointer to a kernel-level representation of a standard Linux block device. Take a look at it, see if it's something you can handle, and then tell me what you can do with it."



          At that point, your driver is supposed to read whatever it needs to verify it's the right driver for the filesystem, and then return a structure that includes pointers to further functions your driver can do with that particular filesystem. Or if the filesystem driver does not recognize the data on the disk, it is supposed to return an appropriate error result, and then VFS will either report a failure to userspace or - if filesystem type auto-detection is being performed - will ask another filesystem driver to try.



          The other drivers in the kernel will provide the standard block device interface, so the filesystem driver won't have to implement hardware support. Basically, the filesystem driver can read and write disk blocks using standard kernel-level functions with the device pointer given to it.



          The VFS layer expects the filesystem driver to make a number of standard functions available to the VFS layer; a few of these are mandatory in order for the VFS layer to do anything meaningful with the filesystem, others are optional and you can just return a NULL in place of a pointer to such an optional function.






          share|improve this answer




















          • 1





            This is a pretty good answer though to fully answer the question as stated you'd also need to say a bit about the functionality the block device layer provides for the file system layer to build upon.

            – kasperd
            Mar 24 at 21:06











          • I sort of alluded to that with the "here's a pointer to a standard block device" bit, but good point; I expanded on that.

            – telcoM
            Mar 24 at 21:59











          • This answer, specifically the description of what happens in what order, is divine. Is there some sort of book/website I could read that has descriptions like that for all of "how linux works"?

            – Adam Barnes
            Mar 25 at 0:10











          • You might be interested in Linux Kernel Internals or Linux Device Drivers, 3rd Edition. And of course, there's the option of reading the actual source code.

            – telcoM
            Mar 25 at 0:16



















          4














          Yes a kernel driver can manage a file-system .



          The best solution to mock up , prototype a file-system is to use FUSE . And after you can think about transform it into a kernel driver .



          Wikipedia =>
          https://en.wikipedia.org/wiki/Filesystem_in_Userspace



          Source => https://github.com/libfuse/libfuse



          a tutorial => https://developer.ibm.com/articles/l-fuse/






          share|improve this answer






























            0














            Yes this would typically be done using a kernel driver that can either be loaded as a kernel module or compiled into the kernel.



            You can check out similar filesystem drivers and how they work here.



            These drivers likely use internal kernel functions to access storage devices as blocks of bytes but you could also use blockdevices as exposed by drivers in the block devices and character devices folders.






            share|improve this answer






























              0














              You can use fuse, to make a user-land file-system, or write a kernel module.
              It is easier to do with fuse, as you have a choice of languages, and won't crash the kernel (and therefore the whole system).



              Kernel modules can be faster, but the first rule of optimisation is: Don't do it until you have tested working code. The second is like it: Don't do it until you have evidence that it is too slow. And the third: Don't keep it unless you have evidence that it makes it faster/smaller.



              And yes the kernel already has drivers for the hardware, you don't re-implement them.






              share|improve this answer























              • There are major downsides to FUSE other than performance: it's hard to use it for your root filesystem. (Maybe possible with an initrd, but the FUSE binary couldn't be freed after booting because it would still be executing from the ramdisk.)

                – Peter Cordes
                Mar 24 at 19:52






              • 1





                @PeterCordes It couldn't be freed, but that doesn't mean it can't be unlinked. If there's still a reference to it, it'll be kept in memory regardless of whether or not you left the initramfs and deleted the underlying binary.

                – forest
                Mar 25 at 8:39











              • @forest: right, therefore you can't unmount the initrd after pivot_root, because there are still busy inodes in the initramfs.

                – Peter Cordes
                Mar 25 at 8:53












              • A normal /init started from an initramfs will (I think) execve /init after pivot_root, to transfer control to the real root FS's /init. But a FUSE binary couldn't replace itself with execve if access to the root FS depended on the FUSE process responding to the kernel. Well maybe by priming the pagecache first, but that doesn't sound reliable.

                – Peter Cordes
                Mar 25 at 8:58


















              4 Answers
              4






              active

              oldest

              votes








              4 Answers
              4






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              23














              Yes, filesystems in Linux can be implemented as kernel modules. But there is also the FUSE (Filesystem in USErspace) interface, which can allow a regular user-space process to act as a filesystem driver. If you're prototyping a new filesystem, implementing it first using the FUSE interface could make the testing and development easier. Once you have the internals of the filesystem worked out in FUSE form, you might then start implementing a performance-optimized kernel module version of it.



              Here's some basic information on implementing a filesystem within kernel space. It's rather old (from 1996!), but that should at least give you a basic idea for the kind of things you'll need to do.



              If you choose to go to the FUSE route, here's libfuse, the reference implementation of the userspace side of the FUSE interface.



              Filesystem driver as a kernel module



              Basically, the initialization function of your filesystem driver module needs just to call a register_filesystem() function, and give it as a parameter a structure that includes a function pointer that identifies the function in your filesystem driver that will be used as the first step in identifying your filesystem type and mounting it. Nothing more happens at that stage.



              When a filesystem is being mounted, and either the filesystem type is specified to match your driver, or filesystem type auto-detection is being performed, the kernel's Virtual FileSystem (VFS for short) layer will call that function. It basically says "Here's a pointer to a kernel-level representation of a standard Linux block device. Take a look at it, see if it's something you can handle, and then tell me what you can do with it."



              At that point, your driver is supposed to read whatever it needs to verify it's the right driver for the filesystem, and then return a structure that includes pointers to further functions your driver can do with that particular filesystem. Or if the filesystem driver does not recognize the data on the disk, it is supposed to return an appropriate error result, and then VFS will either report a failure to userspace or - if filesystem type auto-detection is being performed - will ask another filesystem driver to try.



              The other drivers in the kernel will provide the standard block device interface, so the filesystem driver won't have to implement hardware support. Basically, the filesystem driver can read and write disk blocks using standard kernel-level functions with the device pointer given to it.



              The VFS layer expects the filesystem driver to make a number of standard functions available to the VFS layer; a few of these are mandatory in order for the VFS layer to do anything meaningful with the filesystem, others are optional and you can just return a NULL in place of a pointer to such an optional function.






              share|improve this answer




















              • 1





                This is a pretty good answer though to fully answer the question as stated you'd also need to say a bit about the functionality the block device layer provides for the file system layer to build upon.

                – kasperd
                Mar 24 at 21:06











              • I sort of alluded to that with the "here's a pointer to a standard block device" bit, but good point; I expanded on that.

                – telcoM
                Mar 24 at 21:59











              • This answer, specifically the description of what happens in what order, is divine. Is there some sort of book/website I could read that has descriptions like that for all of "how linux works"?

                – Adam Barnes
                Mar 25 at 0:10











              • You might be interested in Linux Kernel Internals or Linux Device Drivers, 3rd Edition. And of course, there's the option of reading the actual source code.

                – telcoM
                Mar 25 at 0:16
















              23














              Yes, filesystems in Linux can be implemented as kernel modules. But there is also the FUSE (Filesystem in USErspace) interface, which can allow a regular user-space process to act as a filesystem driver. If you're prototyping a new filesystem, implementing it first using the FUSE interface could make the testing and development easier. Once you have the internals of the filesystem worked out in FUSE form, you might then start implementing a performance-optimized kernel module version of it.



              Here's some basic information on implementing a filesystem within kernel space. It's rather old (from 1996!), but that should at least give you a basic idea for the kind of things you'll need to do.



              If you choose to go to the FUSE route, here's libfuse, the reference implementation of the userspace side of the FUSE interface.



              Filesystem driver as a kernel module



              Basically, the initialization function of your filesystem driver module needs just to call a register_filesystem() function, and give it as a parameter a structure that includes a function pointer that identifies the function in your filesystem driver that will be used as the first step in identifying your filesystem type and mounting it. Nothing more happens at that stage.



              When a filesystem is being mounted, and either the filesystem type is specified to match your driver, or filesystem type auto-detection is being performed, the kernel's Virtual FileSystem (VFS for short) layer will call that function. It basically says "Here's a pointer to a kernel-level representation of a standard Linux block device. Take a look at it, see if it's something you can handle, and then tell me what you can do with it."



              At that point, your driver is supposed to read whatever it needs to verify it's the right driver for the filesystem, and then return a structure that includes pointers to further functions your driver can do with that particular filesystem. Or if the filesystem driver does not recognize the data on the disk, it is supposed to return an appropriate error result, and then VFS will either report a failure to userspace or - if filesystem type auto-detection is being performed - will ask another filesystem driver to try.



              The other drivers in the kernel will provide the standard block device interface, so the filesystem driver won't have to implement hardware support. Basically, the filesystem driver can read and write disk blocks using standard kernel-level functions with the device pointer given to it.



              The VFS layer expects the filesystem driver to make a number of standard functions available to the VFS layer; a few of these are mandatory in order for the VFS layer to do anything meaningful with the filesystem, others are optional and you can just return a NULL in place of a pointer to such an optional function.






              share|improve this answer




















              • 1





                This is a pretty good answer though to fully answer the question as stated you'd also need to say a bit about the functionality the block device layer provides for the file system layer to build upon.

                – kasperd
                Mar 24 at 21:06











              • I sort of alluded to that with the "here's a pointer to a standard block device" bit, but good point; I expanded on that.

                – telcoM
                Mar 24 at 21:59











              • This answer, specifically the description of what happens in what order, is divine. Is there some sort of book/website I could read that has descriptions like that for all of "how linux works"?

                – Adam Barnes
                Mar 25 at 0:10











              • You might be interested in Linux Kernel Internals or Linux Device Drivers, 3rd Edition. And of course, there's the option of reading the actual source code.

                – telcoM
                Mar 25 at 0:16














              23












              23








              23







              Yes, filesystems in Linux can be implemented as kernel modules. But there is also the FUSE (Filesystem in USErspace) interface, which can allow a regular user-space process to act as a filesystem driver. If you're prototyping a new filesystem, implementing it first using the FUSE interface could make the testing and development easier. Once you have the internals of the filesystem worked out in FUSE form, you might then start implementing a performance-optimized kernel module version of it.



              Here's some basic information on implementing a filesystem within kernel space. It's rather old (from 1996!), but that should at least give you a basic idea for the kind of things you'll need to do.



              If you choose to go to the FUSE route, here's libfuse, the reference implementation of the userspace side of the FUSE interface.



              Filesystem driver as a kernel module



              Basically, the initialization function of your filesystem driver module needs just to call a register_filesystem() function, and give it as a parameter a structure that includes a function pointer that identifies the function in your filesystem driver that will be used as the first step in identifying your filesystem type and mounting it. Nothing more happens at that stage.



              When a filesystem is being mounted, and either the filesystem type is specified to match your driver, or filesystem type auto-detection is being performed, the kernel's Virtual FileSystem (VFS for short) layer will call that function. It basically says "Here's a pointer to a kernel-level representation of a standard Linux block device. Take a look at it, see if it's something you can handle, and then tell me what you can do with it."



              At that point, your driver is supposed to read whatever it needs to verify it's the right driver for the filesystem, and then return a structure that includes pointers to further functions your driver can do with that particular filesystem. Or if the filesystem driver does not recognize the data on the disk, it is supposed to return an appropriate error result, and then VFS will either report a failure to userspace or - if filesystem type auto-detection is being performed - will ask another filesystem driver to try.



              The other drivers in the kernel will provide the standard block device interface, so the filesystem driver won't have to implement hardware support. Basically, the filesystem driver can read and write disk blocks using standard kernel-level functions with the device pointer given to it.



              The VFS layer expects the filesystem driver to make a number of standard functions available to the VFS layer; a few of these are mandatory in order for the VFS layer to do anything meaningful with the filesystem, others are optional and you can just return a NULL in place of a pointer to such an optional function.






              share|improve this answer















              Yes, filesystems in Linux can be implemented as kernel modules. But there is also the FUSE (Filesystem in USErspace) interface, which can allow a regular user-space process to act as a filesystem driver. If you're prototyping a new filesystem, implementing it first using the FUSE interface could make the testing and development easier. Once you have the internals of the filesystem worked out in FUSE form, you might then start implementing a performance-optimized kernel module version of it.



              Here's some basic information on implementing a filesystem within kernel space. It's rather old (from 1996!), but that should at least give you a basic idea for the kind of things you'll need to do.



              If you choose to go to the FUSE route, here's libfuse, the reference implementation of the userspace side of the FUSE interface.



              Filesystem driver as a kernel module



              Basically, the initialization function of your filesystem driver module needs just to call a register_filesystem() function, and give it as a parameter a structure that includes a function pointer that identifies the function in your filesystem driver that will be used as the first step in identifying your filesystem type and mounting it. Nothing more happens at that stage.



              When a filesystem is being mounted, and either the filesystem type is specified to match your driver, or filesystem type auto-detection is being performed, the kernel's Virtual FileSystem (VFS for short) layer will call that function. It basically says "Here's a pointer to a kernel-level representation of a standard Linux block device. Take a look at it, see if it's something you can handle, and then tell me what you can do with it."



              At that point, your driver is supposed to read whatever it needs to verify it's the right driver for the filesystem, and then return a structure that includes pointers to further functions your driver can do with that particular filesystem. Or if the filesystem driver does not recognize the data on the disk, it is supposed to return an appropriate error result, and then VFS will either report a failure to userspace or - if filesystem type auto-detection is being performed - will ask another filesystem driver to try.



              The other drivers in the kernel will provide the standard block device interface, so the filesystem driver won't have to implement hardware support. Basically, the filesystem driver can read and write disk blocks using standard kernel-level functions with the device pointer given to it.



              The VFS layer expects the filesystem driver to make a number of standard functions available to the VFS layer; a few of these are mandatory in order for the VFS layer to do anything meaningful with the filesystem, others are optional and you can just return a NULL in place of a pointer to such an optional function.







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Mar 24 at 21:58

























              answered Mar 24 at 14:35









              telcoMtelcoM

              21.1k12553




              21.1k12553







              • 1





                This is a pretty good answer though to fully answer the question as stated you'd also need to say a bit about the functionality the block device layer provides for the file system layer to build upon.

                – kasperd
                Mar 24 at 21:06











              • I sort of alluded to that with the "here's a pointer to a standard block device" bit, but good point; I expanded on that.

                – telcoM
                Mar 24 at 21:59











              • This answer, specifically the description of what happens in what order, is divine. Is there some sort of book/website I could read that has descriptions like that for all of "how linux works"?

                – Adam Barnes
                Mar 25 at 0:10











              • You might be interested in Linux Kernel Internals or Linux Device Drivers, 3rd Edition. And of course, there's the option of reading the actual source code.

                – telcoM
                Mar 25 at 0:16













              • 1





                This is a pretty good answer though to fully answer the question as stated you'd also need to say a bit about the functionality the block device layer provides for the file system layer to build upon.

                – kasperd
                Mar 24 at 21:06











              • I sort of alluded to that with the "here's a pointer to a standard block device" bit, but good point; I expanded on that.

                – telcoM
                Mar 24 at 21:59











              • This answer, specifically the description of what happens in what order, is divine. Is there some sort of book/website I could read that has descriptions like that for all of "how linux works"?

                – Adam Barnes
                Mar 25 at 0:10











              • You might be interested in Linux Kernel Internals or Linux Device Drivers, 3rd Edition. And of course, there's the option of reading the actual source code.

                – telcoM
                Mar 25 at 0:16








              1




              1





              This is a pretty good answer though to fully answer the question as stated you'd also need to say a bit about the functionality the block device layer provides for the file system layer to build upon.

              – kasperd
              Mar 24 at 21:06





              This is a pretty good answer though to fully answer the question as stated you'd also need to say a bit about the functionality the block device layer provides for the file system layer to build upon.

              – kasperd
              Mar 24 at 21:06













              I sort of alluded to that with the "here's a pointer to a standard block device" bit, but good point; I expanded on that.

              – telcoM
              Mar 24 at 21:59





              I sort of alluded to that with the "here's a pointer to a standard block device" bit, but good point; I expanded on that.

              – telcoM
              Mar 24 at 21:59













              This answer, specifically the description of what happens in what order, is divine. Is there some sort of book/website I could read that has descriptions like that for all of "how linux works"?

              – Adam Barnes
              Mar 25 at 0:10





              This answer, specifically the description of what happens in what order, is divine. Is there some sort of book/website I could read that has descriptions like that for all of "how linux works"?

              – Adam Barnes
              Mar 25 at 0:10













              You might be interested in Linux Kernel Internals or Linux Device Drivers, 3rd Edition. And of course, there's the option of reading the actual source code.

              – telcoM
              Mar 25 at 0:16






              You might be interested in Linux Kernel Internals or Linux Device Drivers, 3rd Edition. And of course, there's the option of reading the actual source code.

              – telcoM
              Mar 25 at 0:16














              4














              Yes a kernel driver can manage a file-system .



              The best solution to mock up , prototype a file-system is to use FUSE . And after you can think about transform it into a kernel driver .



              Wikipedia =>
              https://en.wikipedia.org/wiki/Filesystem_in_Userspace



              Source => https://github.com/libfuse/libfuse



              a tutorial => https://developer.ibm.com/articles/l-fuse/






              share|improve this answer



























                4














                Yes a kernel driver can manage a file-system .



                The best solution to mock up , prototype a file-system is to use FUSE . And after you can think about transform it into a kernel driver .



                Wikipedia =>
                https://en.wikipedia.org/wiki/Filesystem_in_Userspace



                Source => https://github.com/libfuse/libfuse



                a tutorial => https://developer.ibm.com/articles/l-fuse/






                share|improve this answer

























                  4












                  4








                  4







                  Yes a kernel driver can manage a file-system .



                  The best solution to mock up , prototype a file-system is to use FUSE . And after you can think about transform it into a kernel driver .



                  Wikipedia =>
                  https://en.wikipedia.org/wiki/Filesystem_in_Userspace



                  Source => https://github.com/libfuse/libfuse



                  a tutorial => https://developer.ibm.com/articles/l-fuse/






                  share|improve this answer













                  Yes a kernel driver can manage a file-system .



                  The best solution to mock up , prototype a file-system is to use FUSE . And after you can think about transform it into a kernel driver .



                  Wikipedia =>
                  https://en.wikipedia.org/wiki/Filesystem_in_Userspace



                  Source => https://github.com/libfuse/libfuse



                  a tutorial => https://developer.ibm.com/articles/l-fuse/







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Mar 24 at 14:00









                  EchoMike444EchoMike444

                  1,07017




                  1,07017





















                      0














                      Yes this would typically be done using a kernel driver that can either be loaded as a kernel module or compiled into the kernel.



                      You can check out similar filesystem drivers and how they work here.



                      These drivers likely use internal kernel functions to access storage devices as blocks of bytes but you could also use blockdevices as exposed by drivers in the block devices and character devices folders.






                      share|improve this answer



























                        0














                        Yes this would typically be done using a kernel driver that can either be loaded as a kernel module or compiled into the kernel.



                        You can check out similar filesystem drivers and how they work here.



                        These drivers likely use internal kernel functions to access storage devices as blocks of bytes but you could also use blockdevices as exposed by drivers in the block devices and character devices folders.






                        share|improve this answer

























                          0












                          0








                          0







                          Yes this would typically be done using a kernel driver that can either be loaded as a kernel module or compiled into the kernel.



                          You can check out similar filesystem drivers and how they work here.



                          These drivers likely use internal kernel functions to access storage devices as blocks of bytes but you could also use blockdevices as exposed by drivers in the block devices and character devices folders.






                          share|improve this answer













                          Yes this would typically be done using a kernel driver that can either be loaded as a kernel module or compiled into the kernel.



                          You can check out similar filesystem drivers and how they work here.



                          These drivers likely use internal kernel functions to access storage devices as blocks of bytes but you could also use blockdevices as exposed by drivers in the block devices and character devices folders.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Mar 24 at 13:31









                          ErikErik

                          31




                          31





















                              0














                              You can use fuse, to make a user-land file-system, or write a kernel module.
                              It is easier to do with fuse, as you have a choice of languages, and won't crash the kernel (and therefore the whole system).



                              Kernel modules can be faster, but the first rule of optimisation is: Don't do it until you have tested working code. The second is like it: Don't do it until you have evidence that it is too slow. And the third: Don't keep it unless you have evidence that it makes it faster/smaller.



                              And yes the kernel already has drivers for the hardware, you don't re-implement them.






                              share|improve this answer























                              • There are major downsides to FUSE other than performance: it's hard to use it for your root filesystem. (Maybe possible with an initrd, but the FUSE binary couldn't be freed after booting because it would still be executing from the ramdisk.)

                                – Peter Cordes
                                Mar 24 at 19:52






                              • 1





                                @PeterCordes It couldn't be freed, but that doesn't mean it can't be unlinked. If there's still a reference to it, it'll be kept in memory regardless of whether or not you left the initramfs and deleted the underlying binary.

                                – forest
                                Mar 25 at 8:39











                              • @forest: right, therefore you can't unmount the initrd after pivot_root, because there are still busy inodes in the initramfs.

                                – Peter Cordes
                                Mar 25 at 8:53












                              • A normal /init started from an initramfs will (I think) execve /init after pivot_root, to transfer control to the real root FS's /init. But a FUSE binary couldn't replace itself with execve if access to the root FS depended on the FUSE process responding to the kernel. Well maybe by priming the pagecache first, but that doesn't sound reliable.

                                – Peter Cordes
                                Mar 25 at 8:58
















                              0














                              You can use fuse, to make a user-land file-system, or write a kernel module.
                              It is easier to do with fuse, as you have a choice of languages, and won't crash the kernel (and therefore the whole system).



                              Kernel modules can be faster, but the first rule of optimisation is: Don't do it until you have tested working code. The second is like it: Don't do it until you have evidence that it is too slow. And the third: Don't keep it unless you have evidence that it makes it faster/smaller.



                              And yes the kernel already has drivers for the hardware, you don't re-implement them.






                              share|improve this answer























                              • There are major downsides to FUSE other than performance: it's hard to use it for your root filesystem. (Maybe possible with an initrd, but the FUSE binary couldn't be freed after booting because it would still be executing from the ramdisk.)

                                – Peter Cordes
                                Mar 24 at 19:52






                              • 1





                                @PeterCordes It couldn't be freed, but that doesn't mean it can't be unlinked. If there's still a reference to it, it'll be kept in memory regardless of whether or not you left the initramfs and deleted the underlying binary.

                                – forest
                                Mar 25 at 8:39











                              • @forest: right, therefore you can't unmount the initrd after pivot_root, because there are still busy inodes in the initramfs.

                                – Peter Cordes
                                Mar 25 at 8:53












                              • A normal /init started from an initramfs will (I think) execve /init after pivot_root, to transfer control to the real root FS's /init. But a FUSE binary couldn't replace itself with execve if access to the root FS depended on the FUSE process responding to the kernel. Well maybe by priming the pagecache first, but that doesn't sound reliable.

                                – Peter Cordes
                                Mar 25 at 8:58














                              0












                              0








                              0







                              You can use fuse, to make a user-land file-system, or write a kernel module.
                              It is easier to do with fuse, as you have a choice of languages, and won't crash the kernel (and therefore the whole system).



                              Kernel modules can be faster, but the first rule of optimisation is: Don't do it until you have tested working code. The second is like it: Don't do it until you have evidence that it is too slow. And the third: Don't keep it unless you have evidence that it makes it faster/smaller.



                              And yes the kernel already has drivers for the hardware, you don't re-implement them.






                              share|improve this answer













                              You can use fuse, to make a user-land file-system, or write a kernel module.
                              It is easier to do with fuse, as you have a choice of languages, and won't crash the kernel (and therefore the whole system).



                              Kernel modules can be faster, but the first rule of optimisation is: Don't do it until you have tested working code. The second is like it: Don't do it until you have evidence that it is too slow. And the third: Don't keep it unless you have evidence that it makes it faster/smaller.



                              And yes the kernel already has drivers for the hardware, you don't re-implement them.







                              share|improve this answer












                              share|improve this answer



                              share|improve this answer










                              answered Mar 24 at 14:14









                              ctrl-alt-delorctrl-alt-delor

                              12.5k52663




                              12.5k52663












                              • There are major downsides to FUSE other than performance: it's hard to use it for your root filesystem. (Maybe possible with an initrd, but the FUSE binary couldn't be freed after booting because it would still be executing from the ramdisk.)

                                – Peter Cordes
                                Mar 24 at 19:52






                              • 1





                                @PeterCordes It couldn't be freed, but that doesn't mean it can't be unlinked. If there's still a reference to it, it'll be kept in memory regardless of whether or not you left the initramfs and deleted the underlying binary.

                                – forest
                                Mar 25 at 8:39











                              • @forest: right, therefore you can't unmount the initrd after pivot_root, because there are still busy inodes in the initramfs.

                                – Peter Cordes
                                Mar 25 at 8:53












                              • A normal /init started from an initramfs will (I think) execve /init after pivot_root, to transfer control to the real root FS's /init. But a FUSE binary couldn't replace itself with execve if access to the root FS depended on the FUSE process responding to the kernel. Well maybe by priming the pagecache first, but that doesn't sound reliable.

                                – Peter Cordes
                                Mar 25 at 8:58


















                              • There are major downsides to FUSE other than performance: it's hard to use it for your root filesystem. (Maybe possible with an initrd, but the FUSE binary couldn't be freed after booting because it would still be executing from the ramdisk.)

                                – Peter Cordes
                                Mar 24 at 19:52






                              • 1





                                @PeterCordes It couldn't be freed, but that doesn't mean it can't be unlinked. If there's still a reference to it, it'll be kept in memory regardless of whether or not you left the initramfs and deleted the underlying binary.

                                – forest
                                Mar 25 at 8:39











                              • @forest: right, therefore you can't unmount the initrd after pivot_root, because there are still busy inodes in the initramfs.

                                – Peter Cordes
                                Mar 25 at 8:53












                              • A normal /init started from an initramfs will (I think) execve /init after pivot_root, to transfer control to the real root FS's /init. But a FUSE binary couldn't replace itself with execve if access to the root FS depended on the FUSE process responding to the kernel. Well maybe by priming the pagecache first, but that doesn't sound reliable.

                                – Peter Cordes
                                Mar 25 at 8:58

















                              There are major downsides to FUSE other than performance: it's hard to use it for your root filesystem. (Maybe possible with an initrd, but the FUSE binary couldn't be freed after booting because it would still be executing from the ramdisk.)

                              – Peter Cordes
                              Mar 24 at 19:52





                              There are major downsides to FUSE other than performance: it's hard to use it for your root filesystem. (Maybe possible with an initrd, but the FUSE binary couldn't be freed after booting because it would still be executing from the ramdisk.)

                              – Peter Cordes
                              Mar 24 at 19:52




                              1




                              1





                              @PeterCordes It couldn't be freed, but that doesn't mean it can't be unlinked. If there's still a reference to it, it'll be kept in memory regardless of whether or not you left the initramfs and deleted the underlying binary.

                              – forest
                              Mar 25 at 8:39





                              @PeterCordes It couldn't be freed, but that doesn't mean it can't be unlinked. If there's still a reference to it, it'll be kept in memory regardless of whether or not you left the initramfs and deleted the underlying binary.

                              – forest
                              Mar 25 at 8:39













                              @forest: right, therefore you can't unmount the initrd after pivot_root, because there are still busy inodes in the initramfs.

                              – Peter Cordes
                              Mar 25 at 8:53






                              @forest: right, therefore you can't unmount the initrd after pivot_root, because there are still busy inodes in the initramfs.

                              – Peter Cordes
                              Mar 25 at 8:53














                              A normal /init started from an initramfs will (I think) execve /init after pivot_root, to transfer control to the real root FS's /init. But a FUSE binary couldn't replace itself with execve if access to the root FS depended on the FUSE process responding to the kernel. Well maybe by priming the pagecache first, but that doesn't sound reliable.

                              – Peter Cordes
                              Mar 25 at 8:58






                              A normal /init started from an initramfs will (I think) execve /init after pivot_root, to transfer control to the real root FS's /init. But a FUSE binary couldn't replace itself with execve if access to the root FS depended on the FUSE process responding to the kernel. Well maybe by priming the pagecache first, but that doesn't sound reliable.

                              – Peter Cordes
                              Mar 25 at 8:58




                              Popular posts from this blog

                              Færeyskur hestur Heimild | Tengill | Tilvísanir | LeiðsagnarvalRossið - síða um færeyska hrossið á færeyskuGott ár hjá færeyska hestinum

                              He _____ here since 1970 . Answer needed [closed]What does “since he was so high” mean?Meaning of “catch birds for”?How do I ensure “since” takes the meaning I want?“Who cares here” meaningWhat does “right round toward” mean?the time tense (had now been detected)What does the phrase “ring around the roses” mean here?Correct usage of “visited upon”Meaning of “foiled rail sabotage bid”It was the third time I had gone to Rome or It is the third time I had been to Rome

                              Bunad