[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190830154318.ppggurnejlgtrly5@pali>
Date: Fri, 30 Aug 2019 17:43:18 +0200
From: Pali Rohár <pali.rohar@...il.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
devel@...verdev.osuosl.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org,
Valdis Klētnieks <valdis.kletnieks@...edu>,
Sasha Levin <alexander.levin@...rosoft.com>
Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to staging
On Friday 30 August 2019 08:40:06 Christoph Hellwig wrote:
> On Thu, Aug 29, 2019 at 10:56:31PM +0200, Pali Rohár wrote:
> > In my opinion, proper way should be to implement exFAT support into
> > existing fs/fat/ code instead of replacing whole vfat/msdosfs by this
> > new (now staging) fat implementation.
> >
> > In linux kernel we really do not need two different implementation of
> > VFAT32.
>
> Not only not useful, but having another one is actively harmful, as
> people might actually accidentally used it for classic fat.
>
> But what I'm really annoyed at is this whole culture of just dumping
> some crap into staging and hoping it'll sort itself out. Which it
> won't. We'll need a dedidcated developer spending some time on it
> and just get it into shape, and having it in staging does not help
> with that at all - it will get various random cleanup that could
> be trivially scripted, but that is rarely the main issue with any
> codebase.
Exactly. Somebody should take this code and work on it. Otherwise we can
say it is dead code and would happen same thing as with other staging
drivers -- ready to be removed.
--
Pali Rohár
pali.rohar@...il.com
Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)
Powered by blists - more mailing lists