linux-kernel - Re: [GIT PULL] Ext3 removal, quota & udf fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55E4F03C.1010708@gmail.com>
Date:	Mon, 31 Aug 2015 17:24:28 -0700
From:	Raymond Jennings <shentino@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jan Kara <jack@...e.cz>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [GIT PULL] Ext3 removal, quota & udf fixes

On 08/31/15 15:31, Raymond Jennings wrote:
> On 08/31/15 14:37, Linus Torvalds wrote:
>> On Sun, Aug 30, 2015 at 11:19 PM, Jan Kara <jack@...e.cz> wrote:
>>> The biggest change in the pull is the removal of ext3 filesystem driver
>>> (~28k lines removed).
>> I really am not ready to just remove ext3 without a lot of good
>> arguments. There might well be people who this use ext3 as ext3, and
>> don't want to update. I want more a rationale for removal than "ext4
>> can read old ext3 filesystems".
> I actually would agree that having two drivers for the same filesystem 
> is redundant and unneeded code duplication.
>
> That said, I wouldn't mind myself if the ext4 driver were given a very 
> grueling regression test to make sure it can actually handle old ext3 
> systems as well as the ext3 driver can.  Just gutting an entire driver 
> because another driver can handle it only makes sense if nothing can 
> go wrong and the potential for causing regressions is quite obvious.
>
> I think also that we should remove the ext2 driver before we remove 
> the ext3 driver.
>
> My two cents.
Just to ask a general opinion:

Am I right that it's ok for kernel code to be organized how we (the 
developers) see fit as long as we don't break userspace or hardware in 
the process?

So long as we function properly, should userspace care about how our 
source code is structured?

I'm thinking yes, but it might be fruitful to see an answer archived on 
the list.
>>                    Linus
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-kernel" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/