Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1410305 > unrolled thread

[PATCH] befs: remove unused endian functions

Back to article view | Back to linux.kernel

Contents

  [PATCH] befs: remove unused endian functions Luis de Bethencourt <luisbg@osg.samsung.com> - 2016-05-31 15:30 +0200
    Re: [PATCH] befs: remove unused endian functions Al Viro <viro@ZenIV.linux.org.uk> - 2016-05-31 23:00 +0200
      Re: [PATCH] befs: remove unused endian functions Luis de Bethencourt <luisbg@osg.samsung.com> - 2016-05-31 23:00 +0200
        Re: [PATCH] befs: remove unused endian functions Andrew Morton <akpm@linux-foundation.org> - 2016-06-01 21:30 +0200
          Re: [PATCH] befs: remove unused endian functions Andrew Morton <akpm@linux-foundation.org> - 2016-06-01 21:40 +0200
            Re: [PATCH] befs: remove unused endian functions Luis de Bethencourt <luisbg@osg.samsung.com> - 2016-06-01 21:50 +0200
          Re: [PATCH] befs: remove unused endian functions Luis de Bethencourt <luisbg@osg.samsung.com> - 2016-06-01 21:40 +0200

#1410305 — [PATCH] befs: remove unused endian functions

Remove endianness conversion functions that are declared but never used.

Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
---

Hi,

Continuing to learn the BeFS code. Noticed some cleanup.

Thanks for the review :)

Luis

 fs/befs/endian.h | 44 --------------------------------------------
 1 file changed, 44 deletions(-)

diff --git a/fs/befs/endian.h b/fs/befs/endian.h
index 2722387..3163ee6 100644
--- a/fs/befs/endian.h
+++ b/fs/befs/endian.h
@@ -20,15 +20,6 @@ fs64_to_cpu(const struct super_block *sb, fs64 n)
 		return be64_to_cpu((__force __be64)n);
 }
 
-static inline fs64
-cpu_to_fs64(const struct super_block *sb, u64 n)
-{
-	if (BEFS_SB(sb)->byte_order == BEFS_BYTESEX_LE)
-		return (__force fs64)cpu_to_le64(n);
-	else
-		return (__force fs64)cpu_to_be64(n);
-}
-
 static inline u32
 fs32_to_cpu(const struct super_block *sb, fs32 n)
 {
@@ -38,15 +29,6 @@ fs32_to_cpu(const struct super_block *sb, fs32 n)
 		return be32_to_cpu((__force __be32)n);
 }
 
-static inline fs32
-cpu_to_fs32(const struct super_block *sb, u32 n)
-{
-	if (BEFS_SB(sb)->byte_order == BEFS_BYTESEX_LE)
-		return (__force fs32)cpu_to_le32(n);
-	else
-		return (__force fs32)cpu_to_be32(n);
-}
-
 static inline u16
 fs16_to_cpu(const struct super_block *sb, fs16 n)
 {
@@ -56,15 +38,6 @@ fs16_to_cpu(const struct super_block *sb, fs16 n)
 		return be16_to_cpu((__force __be16)n);
 }
 
-static inline fs16
-cpu_to_fs16(const struct super_block *sb, u16 n)
-{
-	if (BEFS_SB(sb)->byte_order == BEFS_BYTESEX_LE)
-		return (__force fs16)cpu_to_le16(n);
-	else
-		return (__force fs16)cpu_to_be16(n);
-}
-
 /* Composite types below here */
 
 static inline befs_block_run
@@ -84,23 +57,6 @@ fsrun_to_cpu(const struct super_block *sb, befs_disk_block_run n)
 	return run;
 }
 
-static inline befs_disk_block_run
-cpu_to_fsrun(const struct super_block *sb, befs_block_run n)
-{
-	befs_disk_block_run run;
-
-	if (BEFS_SB(sb)->byte_order == BEFS_BYTESEX_LE) {
-		run.allocation_group = cpu_to_le32(n.allocation_group);
-		run.start = cpu_to_le16(n.start);
-		run.len = cpu_to_le16(n.len);
-	} else {
-		run.allocation_group = cpu_to_be32(n.allocation_group);
-		run.start = cpu_to_be16(n.start);
-		run.len = cpu_to_be16(n.len);
-	}
-	return run;
-}
-
 static inline befs_data_stream
 fsds_to_cpu(const struct super_block *sb, const befs_disk_data_stream *n)
 {
-- 
2.5.1

[toc] | [next] | [standalone]

#1410620

On Tue, May 31, 2016 at 02:27:57PM +0100, Luis de Bethencourt wrote:
> Remove endianness conversion functions that are declared but never used.

Well...  As long as it stays read-only - sure, you don't need to convert
anything to on-disk types.

[toc] | [prev] | [next] | [standalone]

#1410621

On 31/05/16 21:54, Al Viro wrote:
> On Tue, May 31, 2016 at 02:27:57PM +0100, Luis de Bethencourt wrote:
>> Remove endianness conversion functions that are declared but never used.
> 
> Well...  As long as it stays read-only - sure, you don't need to convert
> anything to on-disk types.
> 

Hello,

While reading the BeFS book "Practical Filesystems" I have gotten really
interested in this and it's why I am reading/learning the Linux
implementation.

The idea of adding write support has crossed my mind, but I wanted to know
if you would be interested in this before I start looking into it. Are you?

It would take some time and there are other things to clean in the befs code
first though.

Thanks,
Luis

[toc] | [prev] | [next] | [standalone]

#1411490

On Tue, 31 May 2016 21:59:03 +0100 Luis de Bethencourt <luisbg@osg.samsung.com> wrote:

> On 31/05/16 21:54, Al Viro wrote:
> > On Tue, May 31, 2016 at 02:27:57PM +0100, Luis de Bethencourt wrote:
> >> Remove endianness conversion functions that are declared but never used.
> > 
> > Well...  As long as it stays read-only - sure, you don't need to convert
> > anything to on-disk types.

I think it would be best to leave the code as-is.  The compiler will
remove it all so there's a very small amount of compile-time cost.  We
could just comment the code out but then they would rot over time,

> 
> Hello,
> 
> While reading the BeFS book "Practical Filesystems" I have gotten really
> interested in this and it's why I am reading/learning the Linux
> implementation.
> 
> The idea of adding write support has crossed my mind, but I wanted to know
> if you would be interested in this before I start looking into it. Are you?
> 
> It would take some time and there are other things to clean in the befs code
> first though.

It could be a fun starter project but I have to say, befs is not a very
valuable place in which to spend your time nor is befs the best place
in which to develop familiarity.  A more modest project within a more
mainstream part of the kernel would be a better investment.

[toc] | [prev] | [next] | [standalone]

#1411493

On Wed, 01 Jun 2016 20:31:04 +0100 Luis de Bethencourt <luisbg@osg.samsung.com> wrote:

> Do you have any suggestions of more modest projects within other file systems?
> Something that would be a better time investment.

Nope, sorry :(.  Reading the linux-fsdevel archives might be
worthwhile - look for unaddressed bug reports.  Also
bugzilla.kernel.org and the various distro bugzilla archives may dredge
out issues that remain unaddressed.

[toc] | [prev] | [next] | [standalone]

#1411505

On 01/06/16 20:38, Andrew Morton wrote:
> On Wed, 01 Jun 2016 20:31:04 +0100 Luis de Bethencourt <luisbg@osg.samsung.com> wrote:
> 
>> Do you have any suggestions of more modest projects within other file systems?
>> Something that would be a better time investment.
> 
> Nope, sorry :(.  Reading the linux-fsdevel archives might be
> worthwhile - look for unaddressed bug reports.  Also
> bugzilla.kernel.org and the various distro bugzilla archives may dredge
> out issues that remain unaddressed.
> 

I will do that, I had subscribed to that mailing list but it isn't very active.
Reading the archives is a good idea.

Thanks Andrew, appreciate your time.

Will finish reading the befs code, because it is fun :)
Maybe I will do some cleanup, to help the unmaintained file system. But you are
right that adding write support is too much.

Luis

[toc] | [prev] | [next] | [standalone]

#1411497

On 01/06/16 20:20, Andrew Morton wrote:
> On Tue, 31 May 2016 21:59:03 +0100 Luis de Bethencourt <luisbg@osg.samsung.com> wrote:
> 
>> On 31/05/16 21:54, Al Viro wrote:
>>> On Tue, May 31, 2016 at 02:27:57PM +0100, Luis de Bethencourt wrote:
>>>> Remove endianness conversion functions that are declared but never used.
>>>
>>> Well...  As long as it stays read-only - sure, you don't need to convert
>>> anything to on-disk types.
> 
> I think it would be best to leave the code as-is.  The compiler will
> remove it all so there's a very small amount of compile-time cost.  We
> could just comment the code out but then they would rot over time,
>

Hi Andew,

Sorry for submitting a patch that got nacked. I have two other in befs, but they
are small and trivial.
 
>>
>> Hello,
>>
>> While reading the BeFS book "Practical Filesystems" I have gotten really
>> interested in this and it's why I am reading/learning the Linux
>> implementation.
>>
>> The idea of adding write support has crossed my mind, but I wanted to know
>> if you would be interested in this before I start looking into it. Are you?
>>
>> It would take some time and there are other things to clean in the befs code
>> first though.
> 
> It could be a fun starter project but I have to say, befs is not a very
> valuable place in which to spend your time nor is befs the best place
> in which to develop familiarity.  A more modest project within a more
> mainstream part of the kernel would be a better investment.
> 

That is a good point. One of the reasons I've been reading the Linux
implementation of befs is because it is unmaintained. I thought I could help, but
it also means there isn't huge interest for more support.

Do you have any suggestions of more modest projects within other file systems?
Something that would be a better time investment.

Thanks for the help,
Luis

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web