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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ