Perhaps not a very meaningful voice, but I think it makes sense to split
them.
Johnny
David Holland wrote:
On Mon, Feb 08, 2010 at 11:03:44AM +0900, Masao Uebayashi wrote:
This thread?
http://mail-index.netbsd.org/tech-kern/2009/07/21/msg005526.html
That was later - that's
Hmmm...
Eduardo Horvath wrote:
On Sun, 7 Feb 2010, David Holland wrote:
Anyhow, it seems to me that isolating it from changes to ffs is likely
to result in less breakage over time, not more. Can you expand on your
reasoning some?
The most significant parts that are shared are the directory
On Mon, 8 Feb 2010, Adam Hamsik wrote:
On Feb,Monday 8 2010, at 9:33 PM, Eduardo Horvath wrote:
On Mon, 8 Feb 2010, Adam Hamsik wrote:
Are you sure that you can really finish this ? Currently you are working
on namei, ufs_lookup and many other issues. Make LFS not compilable is the
On Feb,Monday 8 2010, at 10:37 PM, Eduardo Horvath wrote:
On Mon, 8 Feb 2010, Adam Hamsik wrote:
On Feb,Monday 8 2010, at 9:33 PM, Eduardo Horvath wrote:
On Mon, 8 Feb 2010, Adam Hamsik wrote:
Are you sure that you can really finish this ? Currently you are working
on namei,
On several occasions it's been suggested that lfs should be unhooked
from ufs, on the grounds that sharing ufs between both ffs and lfs has
made all three entities (but particularly lfs) gross. ffs and lfs are
not similar enough structurally for this sharing to really be a good
design. Nobody I've
David Holland dholland-t...@netbsd.org wrote:
The copy involves 18 files from sys/ufs/ufs (out of 21; the ones
excluded are quota.h and unsurprisingly ufs_wapbl.[ch]) which contain
9067 lines of code. That gives the following statistics:
14988size of lfs currently
+ 9067
On Sun, Feb 07, 2010 at 10:10:31AM +, Mindaugas Rasiukevicius wrote:
The copy involves 18 files from sys/ufs/ufs (out of 21; the ones
excluded are quota.h and unsurprisingly ufs_wapbl.[ch]) which contain
9067 lines of code. That gives the following statistics:
14988 size
David Holland dholland-curr...@netbsd.org wrote:
How would this affect UFS side? For example, any potential code
reduction and/or simplification?
Yes. ufs_readwrite.c will become much less gross, for example. There
used to be assorted LFS-only code in the ufs sources; ad@ removed the
On Sun, Feb 07, 2010 at 11:07:55AM +, Mindaugas Rasiukevicius wrote:
It was discussed months ago. This is a reminder/heads-up.
Where? This mailing list is a right place where such discussions (and
decisions) should happen.
Right here...
--
David A. Holland
dholl...@netbsd.org
