Skip to contentSkip to conversation

Volunteering for BeFS maintainership

PATCH Luis de Bethencourt 4 participants 11 messages Jul 25, 2016 – Jul 27, 2016 VFS

lore
Share & tools
lore
#0 lore raw

Hi all,

Now that the 4.7 cycle is finished, I want to volunteer myself and Salah Triki for maintainership of the BeFS filesystem.

Salah and myself have been cleaning up the code for the last few months, and since the current status of it is Orphan, it would be great if we could take care of it.

Personally, besides clean ups, I would like to add more documentation of how the file system works, eg. including more function descriptions, so the Linux implementation can be the ideal practical match to Dominic Giampaolo's free book "Practical File System Design with the Be File System".

This book is the most in-depth I've found about any file system, which is why I think having linux/fs/befs well documented would be very valuable to eveybody learning about how file systems work.

I attach below what the change in MAINTAINERS would look like. If this is approved I will send a proper formatted patch mail.

Thanks,
Luis

PD: I don't know if there is a formal process for maintainership in the Linux kernel community. I am happy to follow that if it exists.

Also, if I'm missing anybody who should be in CC, please let me know.

---
 MAINTAINERS | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
MAINTAINERS +3 -1
index 8c20323..7a62abc 100644
@@ -2321,7 +2321,9 @@ S:        Supported
 F:     drivers/media/platform/sti/bdisp
 
 BEFS FILE SYSTEM
-S:     Orphan
+M:     Luis de Bethencourt <[email protected]>
+M:     Salah Triki <[email protected]>
+S:     Mantained
 F:     Documentation/filesystems/befs.txt
 F:     fs/befs/
 

--
2.5.1

#1 lore raw
Quoted 2 lines · Luis de Bethencourt

PD: I don't know if there is a formal process for maintainership in the Linux kernel community. I am happy to follow that if it exists.

If no one objects, and you want to do this, send a real patch and away you go!

Good luck!

greg k-h

#2 lore raw
Quoted 11 lines · Greg KH
Quoted 2 lines · Luis de Bethencourt

PD: I don't know if there is a formal process for maintainership in the Linux kernel community. I am happy to follow that if it exists.

If no one objects, and you want to do this, send a real patch and away you go!

Good luck!

greg k-h

Thanks Greg! :)

I will wait a few days in case other people want to comment before.

Luis

#3 lore raw
Quoted 3 lines · Luis de Bethencourt

I will wait a few days in case other people want to comment before.

Sounds great! Do you have a git tree set up for your befs development?

And if you haven't made plans to use xfstests, I would certainly commend that for your consideration. Don't forget to subscribe to [email protected] to get xfstests announcements. Also, if you're interested in a framework to easily run xfstests in a GCE (Google Compute Engine) VM, feel free to contact me.

Cheers,

- Ted

#4 lore raw
Quoted 7 lines · Theodore Ts'o
Quoted 3 lines · Luis de Bethencourt

I will wait a few days in case other people want to comment before.

Sounds great! Do you have a git tree set up for your befs development?

Thank you :)

Yes, I have the following in github (if that is OK):
https://github.com/luisbg/linux-befs

I have two branches there based on Linus' master:
- befs-linus: with patches Andrew Morton has approved
- befs-next: with patches I've tested but that remain under review

Quoted 10 lines

And if you haven't made plans to use xfstests, I would certainly commend that for your consideration. Don't forget to subscribe to [email protected] to get xfstests announcements. Also, if you're interested in a framework to easily run xfstests in a GCE (Google Compute Engine) VM, feel free to contact me.

Cheers,

- Ted

I've subscribed to [email protected].

It would be amazing to have a framework to run xfstests in a GCE VM.

Big thanks,
Luis

#5 lore raw
Quoted 9 lines · Luis de Bethencourt
Quoted 2 lines

Sounds great! Do you have a git tree set up for your befs development?

Yes, I have the following in github (if that is OK):
https://github.com/luisbg/linux-befs

I have two branches there based on Linus' master:
- befs-linus: with patches Andrew Morton has approved
- befs-next: with patches I've tested but that remain under review

So it sounds like you plan to send patches through Andrew's tree. That works fine, although if you end up sending a larger number of patches through the linux-mm tree, it might make sense for you to send patches to Linus directly. So if you have a chance to get a GPG key which is signed by people in the Kernel keyring, that would be a good preparation for that eventuality. That will require face-to-face verification of your identity by people who are already in the GPG web of trust, so it's good to plan for that in advance.

Quoted 1 line

It would be amazing to have a framework to run xfstests in a GCE VM.

Please see:

https://thunk.org/gce-xfstests

and

https://github.com/tytso/xfstests-bld/blob/master/README.md

for more information.

I plan to do some work to make it simpler to get started using gce-xfstests. (Specifically, so you don't have to build the tree and generate your own GCE image, but instead using a premade one.)

Are there userspace tools available to create and consistency check BeFS file systems? If so, I can try to get those included into the test appliance image. (Better yet, if you can arrange to have someone create a debian package for BeFStools, that would be great.)

- Ted

#6 lore raw
Quoted 4 lines · Theodore Ts'o
Quoted 3 lines · Luis de Bethencourt
Quoted 2 lines

Sounds great! Do you have a git tree set up for your befs development?

Quoted 8 lines
Quoted 6 lines

Yes, I have the following in github (if that is OK):
https://github.com/luisbg/linux-befs

I have two branches there based on Linus' master:
- befs-linus: with patches Andrew Morton has approved
- befs-next: with patches I've tested but that remain under review

So it sounds like you plan to send patches through Andrew's tree.

Not sure. Whatever Andrew, Al, Greg and yourself think is better.

Quoted 7 lines

That works fine, although if you end up sending a larger number of patches through the linux-mm tree, it might make sense for you to send patches to Linus directly. So if you have a chance to get a GPG key which is signed by people in the Kernel keyring, that would be a good preparation for that eventuality. That will require face-to-face verification of your identity by people who are already in the GPG web of trust, so it's good to plan for that in advance.

I will be at ELCE in 3 months [0]. It will be a good opportunity to get my GPG key signed by people in the Kernel keyring. For example Maxime Ripard, who is one of the speakers and in the GPG web of trust [1].

Quoted 5 lines
Quoted 2 lines

It would be amazing to have a framework to run xfstests in a GCE VM.

Please see:

Quoted 7 lines

https://thunk.org/gce-xfstests

and

https://github.com/tytso/xfstests-bld/blob/master/README.md

for more information.

Very nice. Looking forward to playing with it soon, and adding it to my development process. I have learned a lot reading the ext4 code so I am also interested in running the test suite with that.

Quoted 4 lines

I plan to do some work to make it simpler to get started using gce-xfstests. (Specifically, so you don't have to build the tree and generate your own GCE image, but instead using a premade one.)

I will watch out for updates on this on fstests@vger.

Quoted 7 lines

Are there userspace tools available to create and consistency check BeFS file systems? If so, I can try to get those included into the test appliance image. (Better yet, if you can arrange to have someone create a debian package for BeFStools, that would be great.)

- Ted

Support for BeFS in Linux is read-only. So there are no tools to create BeFS file systems. I have a bunch of BeFS images created from Haiku OS that cover most things.

There is no reason a consistency check tool can't be written. I think this could be a fun exercise, I am tempted to add it to my task list :) However this tool can only inform if the file system is consistent, and not really fix it. Similar to "e2fsck -n".

Salah told me he is planning to slowly work on adding read support in the future. But don't want to make any promises/plans on his behalf.

Thanks,
Luis

[0] http://events.linuxfoundation.org/events/embedded-linux-conference-europe/program/schedule
[1] https://www.kernel.org/doc/ksmap/

#7 lore raw
Quoted 3 lines · Luis de Bethencourt

Support for BeFS in Linux is read-only. So there are no tools to create BeFS file systems. I have a bunch of BeFS images created from Haiku OS that cover most things.

Ah, well, pretty much all of the xfstests assume the ability to write into the file system. So it may be a while before using xfstests will make sense for BeFS.

Quoted 4 lines

There is no reason a consistency check tool can't be written. I think this could be a fun exercise, I am tempted to add it to my task list :) However this tool can only inform if the file system is consistent, and not really fix it. Similar to "e2fsck -n".

That's all which is necessary for xfstests --- the idea is that the test will make various changes to the file system, and then correctness is checked both by whether the expected output is printed as the test probes changed the file system state, and by the consistency checker confirming that the file system is in a consistent sane state after each test completes.

Quoted 2 lines

Salah told me he is planning to slowly work on adding read support in the future. But don't want to make any promises/plans on his behalf.

I assume you mean write support in the above paragraph. :-)

Cheers,

- Ted

#8 lore raw
Quoted 14 lines · Theodore Ts'o
Quoted 3 lines · Luis de Bethencourt

Support for BeFS in Linux is read-only. So there are no tools to create BeFS file systems. I have a bunch of BeFS images created from Haiku OS that cover most things.

Ah, well, pretty much all of the xfstests assume the ability to write into the file system. So it may be a while before using xfstests will make sense for BeFS.

Quoted 4 lines

There is no reason a consistency check tool can't be written. I think this could be a fun exercise, I am tempted to add it to my task list :) However this tool can only inform if the file system is consistent, and not really fix it. Similar to "e2fsck -n".

Quoted 7 lines

That's all which is necessary for xfstests --- the idea is that the test will make various changes to the file system, and then correctness is checked both by whether the expected output is printed as the test probes changed the file system state, and by the consistency checker confirming that the file system is in a consistent sane state after each test completes.

Right. It will still be valuable for me to run xfstests for ext4 and btrfs.

Thanks for the advice.

Quoted 5 lines
Quoted 2 lines

Salah told me he is planning to slowly work on adding read support in the future. But don't want to make any promises/plans on his behalf.

I assume you mean write support in the above paragraph. :-)

You assume correctly :) Sorry for the typo.

Quoted 4 lines

Cheers,

- Ted

Thanks,
Luis

#9 lore raw
In reply to Theodore Ts'o
Quoted 13 lines · Theodore Ts'o
Quoted 3 lines · Luis de Bethencourt

I will wait a few days in case other people want to comment before.

Sounds great! Do you have a git tree set up for your befs development?

And if you haven't made plans to use xfstests, I would certainly commend that for your consideration. Don't forget to subscribe to [email protected] to get xfstests announcements. Also, if you're interested in a framework to easily run xfstests in a GCE (Google Compute Engine) VM, feel free to contact me.

Quoted 3 lines

Cheers,

- Ted

Thanx :)

I'm also interested in the GCE VM.

best regards,
salah

#10 lore raw
In reply to Greg KH
Quoted 10 lines · Greg KH
Quoted 2 lines · Luis de Bethencourt

PD: I don't know if there is a formal process for maintainership in the Linux kernel community. I am happy to follow that if it exists.

If no one objects, and you want to do this, send a real patch and away you go!

Good luck!

greg k-h

Thanx greg :)