Date: Sat, 1 Aug 1998 21:34:33 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: green@zone.syracuse.NET (Brian Feldman) Cc: tlambert@primenet.com, mike@smith.net.au, freebsd-current@FreeBSD.ORG Subject: Re: flock(2) problem & fix Message-ID: <199808012134.OAA25705@usr07.primenet.com> In-Reply-To: <Pine.BSF.4.02.9808011334480.1346-100000@zone.baldcom.net> from "Brian Feldman" at Aug 1, 98 01:37:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I think you're right, if nothing than for the fact that it's already the > norm. This is the first time I've ever done kernel hacking, but I've > tested the patch and made a final version of it, a correction of syntax, > but it shouldn't be used because it breaks what you think it would, like > apache, which have been using flocking wrong since the very beginning. But > anyway, I'll post the correct patch, just because I don't want my > dain-bramaged code floating around ;) I've corrected code that didn't do what was supposed to be done simply to have it out there as a corrected reference, too. 8-). The real issue here is not brain damage on your part. It's more like POSIX/UNIX lawyering. A long time ago, before people had source code to kernels, writing application software was very much like team ice-fishing. You'd go to the thickly iced-over lake (the kernel/user system call barrier) and saw holes at the thinnest spots (the system calls themselves). Then you would drop a fishing line down the most likely hole, and using boathooks in all of the remaining holes, you'd try to move the hook around until it was in front of the fish. The point is that what a kernel's system call interface strictly provides, and what an apllication needs from a kernel in order to do what it has to do, are frequently very different things, and in the end, the kernel is there to serve application requests. This is, perhaps, the most important thing about Open Source Software today: until now, application vendors have been fairly restricted in what they could ask a kernel to do on their behalf. No more; for a dire need, the applicaiton developer can change the kernel. For a much less dire need, an application developer of an embedded application can blur the line between the kernel and the application, as necessary, to get an efficient soloution. This is probably why the Windows platforms have taken off. The use of DLL's and VxD's allow the application programmer to treat the OS as if it were an embedded system, whose only purpose is to do whatever is necessary on behalf of supporting their application. The downside is that you get bad interactions if people are allowed to change interfaces at will. Harmonics. Welcome to Tacoma Narrows. To get back to ice fishing, it's like having a lake where you can make as many holes as you want without regulation, but where you have to use the same hole someone else is using if you want to catch the same type of fish they just caught. It's very easy for your line to become tangled in another if everyone fishes in the same hole at the same time. I guess what you did was build an ice fishing shack over a hole, open the door to go inside and start fishing, only to find an old fart already in there, who says "Hey, didn't you see me standing here with this boat hook?". He then gestures to several nearby holes, where there are other guys with boat hooks, and one guy with a fishing rod and complains, "Me and my buddies are fishing!". If nothing else, this should give you a better understanding when us old farts point at a new hole someone is cutting and say "You don't need to do that. See those four holes? Take your fishing rod over to that one, there, then take three boat hooks to the others, then all's ya gotta do...". 8-). 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 freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808012134.OAA25705>