[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120124135629.GB18136@quack.suse.cz>
Date: Tue, 24 Jan 2012 14:56:29 +0100
From: Jan Kara <jack@...e.cz>
To: Ted Ts'o <tytso@....edu>
Cc: Jan Kara <jack@...e.cz>, Aditya Kali <adityakali@...gle.com>,
linux-ext4@...r.kernel.org
Subject: Re: [PATCH] quota: Remove unnecessary definitions
On Mon 23-01-12 16:09:22, Ted Tso wrote:
> On Thu, Jan 19, 2012 at 09:18:49PM +0100, Jan Kara wrote:
> >
> > Ted, after applying this patch, you'll need to run 'make depend' to fixup
> > dependencies in makefiles. I didn't include that in the patch because on my
> > system the dependencies are different and so diff is 1500+ lines.
> >
> > Also I've talked with Aditya and there's no real reason for libquota to be a
> > separate library. So I think it would be best to just make it part of
> > libext2fs. Do you agree?
>
> My current thinking is to rename it to libinternal, and only build it
> statically. It has all sorts of namespace leakage issues, and it's
> not clear any programs outside of e2fsprogs would need it any way.
> What do folks think?
Well, I could see someone interested in modifying quota information on
unmounted fs image. So I believe there is some use in exporting at least
some quota functions. But it's better to export less in the beginning and
add what's needed later than having to maintain crappy API. So I'm OK with
your plan.
BTW one more question: So far I've kept quota format abstractions (taken
from quota-tools) in the quota code in e2fsprogs. But it's not really
needed and it's one of reasons why quota code I wrote for ocfs2-tools
achieves the same functionality in about half amount of lines (and that's
after reductions I already made). But the abstraction could become handy if
you decided to change quota file format. So should I keep the abstraction or
rip it out?
Honza
--
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists