On 7 November 2014 16:59, Garrett D'Amore via illumos-discuss <[email protected]> wrote: > 1. Build times and cost of effort to use and modify the code base. This > individual piece doesn’t add much — maybe only a minute or so to build times. > But we suffer the death of a 1000 cuts.
I don't think keeping libucb around, at least until we can reduce it to some hollow filter library, is a huge burden on the build times. If you're really keen to solve a build time problem, it's probably worth investigating things that might materially affect it: e.g. stub objects/libraries for increased build parallelism. It would be worth doing some kind of GANTT-like chart of the processes that run during a build, to find where the parallelism is (or isn't), and where the long time periods are. People have done similar things with anonymous DTrace and the booting of the system, to find out where we spend all the time there. If the goal is truly to reduce the build time, Amdahl would have us look for the _big_ problems first, where possible. > 2. People mistakenly using the code. The fact that tools for emulex software > may still be using libucb is a case in point . This is just plain evil. There's no reason to just break their software unless we really get something amazing from doing so. It is the basic expectation of empathy for users that is taught (for a reason) in Engineering programmes at University. > 3. Indexing (code searches) add confusion. Go search sometime for symbols > that are duplicated in libbc, libucb, and libc. That’s evil. I’ve > personally found myself confused by looking at the wrong implementation of a > function because of the duplication in libbc. (Note that libc and libbc > differ by exactly one character!) I agree this is a legitimate concern, and Robert and I were discussing this the other day. I would rather we solve this by enhancing the code search tooling. There will always be duplicate or overlapping symbols in a code-base as large as ours, and clearly we cannot solve _every_ overlap by removing code. I think it would be neat to adjust the cscope generation targets, or perhaps cscope itself, to allow searching particular useful subsets of the code -- e.g., kernel-only, or system headers only, or libraries only. That would be genuinely helpful work for people developing the system, and I would think would be basically without contention! > 4. Focus on on retaining compatibility with stuff we don’t test, can’t test, > and that nobody uses winds up making life harder. I don’t know if this is > the specific case here, but I know that for example when I wanted to make > other changes to improve the DDI I ran into problems because of ancient DMA > interfaces that were long ago obsoleted, but are only still used by 16-bit > PCMCIA. (That’s a specific case of ancient legacy crap holding us back.) > > I’m thoroughly committed to making illumos easier to build, easier to > integrate into other products, and generally a nicer place to work. I believe > that elimination of ancient crap I think that you left out some words, there. But, I, too, am keen to make things better. That's why I fix bugs in things, answer questions, look after infrastructure and upstream work from SmartOS where I can. This is, as near as I can tell, what basically _everybody_ is doing -- just not all in the same way. > Furthermore, I believe its time to take a stand — to put a stake in the > ground so to speak. > illumos must have a goal that is more than just the continuation of Solaris > from the mid-90’s. Frankly, divorcing ourselves from some of the ancient and > irrelevant heritage is a good thing here. > I know you don’t agree.. and are probably not alone here. I do not understand why you are so keen to paint people that are reluctant to pull the rug out from existing users as some kind of villains in a pantomime. It's not "us and them" -- we are all just trying to get work done, without breaking stuff that _other people_ are using; stuff that really is not in the way. > I thought I’d try starting with some less contentious stuff first. Maybe I’m > alone here - I want to make changes that increase market share, that make us > modern and relevant, rather than some nostalgic holdover from that company we > used to work for but which no longer exists. It is not really fair to try to sort all changes into a 1-dimensional line from "least" to "most" contentious. Removing rtld4.x and exec/aout seems like attacking something very unlikely to be in use and is probably fine -- especially if it's in the way of the maintenance of some part of the kernel that you are trying to get done. Removing libucb.so will clearly hurt some people, even if only a few, and unless it's really in the way and there is no other way to fix the road block, we may as well leave it until we have a solution that doesn't leave users out in the cold. I've tried to outline a few things above that are valuable work to do -- i.e. enhancing the code search tooling, and examining in detail why the build takes as long as it does. I think these are tasks that, if you are serious about improving the life of the illumos developer, you might consider tackling! They seem like work that is much less likely to break existing software than just culling old libraries, and I cannot see how anybody could argue with "better cscope" or "faster builds". Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
