Date: Wed, 22 Jan 2003 15:30:35 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: Cheen Liao <cheen@synology.com>, Dag-Erling Smorgrav <des@ofug.org>, freebsd-fs@FreeBSD.ORG Subject: %.9 or 4.x for developement (was Re: Transaction File System - a replacement of JFS) Message-ID: <3E2F299B.A919A49F@mindspring.com> References: <20030114192634.75751.qmail@web13505.mail.yahoo.com> <20030117075118.GA3493@HAL9000.homeunix.com> <3E27DA7F.D5DBEFB@mindspring.com> <20030117222410.GA5449@HAL9000.homeunix.com> <001401c2be93$c36c7490$681adf3d@homexp> <xzpn0luwl6h.fsf@flood.ping.uio.no> <3E2DCE86.4C416E28@mindspring.com> <000e01c2c1c3$f7c0b3e0$bb01a8c0@cheennotebook> <20030122104718.A23298@Odin.AC.HMC.Edu>
index | next in thread | previous in thread | raw e-mail
Brooks Davis wrote: > On Wed, Jan 22, 2003 at 11:11:31AM +0800, Cheen Liao wrote: > > Thanks for sharing your experience. This is exactly our concerns. We will > > not work on 5.0 kernel till its code are "stable". > > Frankly, if you use 5.0-RELEASE (not HEAD) its ABI/API as stable as > any other fixed point, but unlike using 4.x it's _much_ closer to what > 5-STABLE will be so this argument is a bit backwards. I personally expect "the right method to use for locking" to change significantly, over time, as people realize that some of the locking code in there now is bogus. That will have a significant impact on the kernel API's. I also think that a lot of the work to "make things work", without changing interface relationships is going to prove to be fultile in the long run, and *that* will have a significant impact on the kernel API's. As one example, ask yourself these questions about the recent (and ongoing) M_NOWAIT discussion: o Why can't all callers wait for the operation to be completed? o Why can't all callers handle an allocation failure gracefully, without blocking in the allocation routine? The answer to these questions is that some code has the ability to unwind state at the layer at which the allocation is attempted, while other code has state spread across several abstration layers, and so can't successfully unwind it (e.g. hold a lock, call a function, hold another lock...). Such code is legacy code. I expect that FreeBSD will eventually have to do what Solaris, SVR4, AIX, and, now, Linux, have done, and simply bite the bullet, and change the abstraction layering so that all resource references get held at the same stack level. Then the answer to the second question becomes "They can.", and the problem goes away because the idea of the flag to signal variant behaviour between code that can and code that can't unwind state, goes away. But what this boils down to is that interfaces are in serious flux in 5.x, and are likely to remain so for a very long time. It's a very bad idea, from the standpoint of ever getting done with something, to put yourself in a position of not knowing if it's your driver that's causing the problem, or if it's a problem that someone introduced into the host OS, and you're among the first people to notice it. It makes it damn hard to know where to go to look for a bug your are experiencing. This is why most people who are doing research in academic or industrial settings pick a stable platform, and do their research there. The sole exception is if the platform *is* your research, which happens only rarely with established platforms in academia, and almost never, in industry. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the messagehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E2F299B.A919A49F>