Date: Thu, 23 Oct 1997 16:57:58 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: darrenr@cyber.com.au (Darren Reed) Cc: tlambert@primenet.com, hackers@freebsd.org Subject: Re: FreeBSD 3.0 kernel API ?! Message-ID: <199710231657.JAA24042@usr02.primenet.com> In-Reply-To: <199710220202.MAA01643@plum.cyber.com.au> from "Darren Reed" at Oct 22, 97 12:02:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > How will you deal with struct ifnet when we rename all the member > > variables from their current names to "opaque_variable_01" through > > "opaque_variable_NN"? Even if you can depend on the structure, you > > can't reasonably expect the kernel internal interface to not change. > > This sort of change I think is, to put it bluntly, fucked. (I'm > probably putting a lot of people who `control' freebsd offside here). > I'd heartily recommend spending time on something worthwhile rather > than going around making life more difficult for people that. > > It's a change for the sake of a change with no reasonable reason to > happen. To recite an old adage: if it's not broken, don't fix it. It's an example of something that you, as a consumer of the kernel, should not be permitted to tie the hands of kernel developers over, and thereby preclude future dependent progress. It's very like my layering changes to the FS, which add nothing functionally, only architecturally. I can only demostrate small pieces of future functionality (like NFS client locking); it's impossible to say what the big picture is like until the future gets here. I, for one, will not bitch about somone opening the curtains to give me a bigger vista, even if I haven't bothered to step through the window (yet). A more real world example would be the VM system changes, which required interface changes. Anyone who wrote a module that implemented a paging policy on NetBSD is rather screwed trying to port the code to FreeBSD because of similar "arbitrary" changes. Arbitrariness is in the eye of the beholder. On the flip side, if you have a problem with a design choice, provide an alternate implementation which still achieves the design goals of the code you are complaining about, without the drawbacks you perceive in the existing code. > blah, time to giveup on FreeBSD and use Linux I think...at least Linus > doesn't allow silly changes that achieve nothing and just cause more > work. ELF? Linux is still not using the ELF features which I believe are the reasons FreeBSD should switch to ELF; there was no real reason to switch Linux to ELF, except to enable future work along the lines identified by myself and others. For Linux, that work has yet to materialize, and there's no immediate significant advantage to having done the switch. Meanwhile, much old code (mostly code using old shared libraries) has been broken in the process. Where are the cannonized-data-interfaces? Where are the NT SCSI and network drivers? Where is the 'ps' that can run against a system dump image, but that doesn't need recompilation when the proc struct changes? Where is section coloring for kernel paging of non-paging code-path kernel pages? Where is the ELF image archiver so the kernel never needs to be recompiled, only it's archive edited? Where are the objects that can be archived into the kernel image, or alternately loaed as LKM's, without rebuilding them? This is all yet nothing more than open curtains in Linux... but it's still desirable to have the curtains open. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710231657.JAA24042>