Date: Thu, 12 Feb 1998 01:39:19 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dg@root.com Cc: tlambert@primenet.com, adrian@obiwan.creative.net.au, jlemon@americantv.com, current@FreeBSD.ORG Subject: Re: Hollywood (Re: PATCH.M ) Message-ID: <199802120139.SAA28932@usr07.primenet.com> In-Reply-To: <199802112000.MAA21439@implode.root.com> from "David Greenman" at Feb 11, 98 12:00:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >When FreeBSD boots, it uses my init_main.c. SYSINIT was *my* baby, > >as is the kernel process starting code used by updated (now syncd), > >etc.. > > Yes, and I recall that SYSINIT was broken and took some frobbing by > Julian to get it to work. I might also mention that some people, myself > included, aren't entirely satisfied with the direction that SYSINIT has > taken us. FWIW, neither am I. The intent was to make it so that you could decide to include a kernel component by linking it or not linking it. Unfortunately, people have continued futzing around with the config program and puting opt_this.h and opt_that.h everywhere, instead of getting rid of conditional compilation in favor of conditional linking, and from there to conditional agregation of seperate object sections (using ELF). In my ideal world, there is no "config". One thing that would encourage this greatly is cutting over to John Polstra's dual ELF/a.out bootblocks, despite the fact that they leave only 34 bytes free, and switching 3.0 over to ELF. As the architect, this is more your department to make a call on. > For one thing, it's made it much more difficult to debug the > system during startup and has made it near impossible to see the > pathologic interaction between various random users of it spread > out over dozens of kernel source files. I'm *very* open to any suggestion on how to deal with pathologic users. If you can come up with a design with the same capabilities that enforces your desired usage model, more power to you. I'd personally be happy with a better level of abstraction in all of the DDI/DKI interfaces, and the kernel inter-subsystem interfaces so that it's finally at least possible to document *preferred* usage. At the very least, preferred usage should be documented by style, but it can't be until there are interfaces that allow it. I think, however, it more a case of "here is a hammer" resulting in people treating everything as a nail. This is endemic to a *lack* of tools interfaces, not their proliferation. > >You are using my LKM code; if you had problems, it's because you > >waited so long, and then acquired it from NetBSD instead of me. > > Unfortunately, you're right. I'm sure even you will agree that it is > not much more than a proof of concept and falls way short of the needs of > any sort of production LKM system. Certainly. I rushed its release for the benefit of "the grand unified console project", delaying the release of my BSD style shared library code, and the next week Novell bought USL, and USL came in, held a meeting, and said work on free UNIX clones was now in violation of Novell employee's non-competition agreements. I stopped contribution then and there because of the lawsuit. In fact, when Chris integrated the LKM code in NetBSD, and it was alpha code (in fact, it had the SunOS manual pages I was using as interface docuementation for the module management programs in the module management source code, in comments -- Copyrighted material; the intent was to distribute *solely* to users who had licenses to the SunOS code for them to comment on how well the interface resembed the SunOS code -- something they couldn't do without the SunOS in hand as a reference). I'm well aware that BSD languished without a good shared library implementation for about a year; I personally sorely missed it, and I'm sure Jeffrey Hsu, who originated the GCC PIC patches and rushed their release for me to use in my shared library effort, was sorely disappointed as well. I'm sure the OSF people, who donated the SunOS shared library source code to be used in the FreeBSD implementation felt a bit betrayed, as well. Unfortunately, I was not in a position to be able to maintain the code I donated. Fortunately, this is no longer the case, and has not been since I left Novell. It's the major reason I left Novell, in fact: inability to do outside research unrelated to my job responsibilities. Research is my method for relieving stress and for keeping engineering fun. You could say I'm in this solely for the fun of it, if you wanted to oversimplify. I'll even go you one further: the SYSINIT/init_main.c code was alpha code, and probably shouldn't have been integrated into FreeBSD as quickly as it was, even given the problems it solved that needed solving. I *still* get email giving me shit over my use of "goto" in about three places in that code, mostly from people who don't understand that compilers kick out JMP instructions. Anyone who has looked at my attempts to get patches into vfs_syscalls.c *knows* that, if *anything*, I will reorganize to use negative logic. I'm a big fan of single-entry/single-exit on function calls, because I understand the kernel preeemption issues FreeBSD will face if it want to support a hard realtime implementation (something I'm also in favor of), or kernel preemption for other reasons, like kernel threads, or the moral equivalen, fine grain SMP. > Look, I'm not interested in putting you down in public. This sort of > pissing match benefits neither of us. I agree; my intent was not to get into a pissing match. Only to refute the implied claims of me being incompetent. There are good reasons why some of my code that people have seen looks bad, either political (USL), or process (update/submit/patch cycle time, use of alpha code simply because it exists, etc.), and so on. Part of it is that the code has been characterized as bad, and now people who haven't seen my production code are making judgments based on other peoples public opinions rather than looking at the code, like they should. > >PS: Did someone specifically kill the mailing of my PATCH.C that > > contained the actual patches? > > No, but I didn't get a copy of it, either. It apparently exceeded filter limits; I will cvs update and repost when I get home tonight. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802120139.SAA28932>