Date: Thu, 26 Feb 1998 04:30:28 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: doconnor@gsoft.com.au, dannyman@sasquatch.dannyland.org, freebsd-current@FreeBSD.ORG Subject: Re: qcam in kernel - build died Message-ID: <199802260430.VAA23682@usr07.primenet.com> In-Reply-To: <21104.888457708@time.cdrom.com> from "Jordan K. Hubbard" at Feb 25, 98 05:48:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> The original author, Paul Traina, indicated that it was badly
> bitrotted and he no longer wished to support it. Since nobody else
> seemed to be looking after it either (the QuickCam VC has been out for
> months and nobody has updated the driver to deal with it), Mike deemed
> it best to simply kill it.
>
> That said, there *was* a certain degree of outcry over the decision
> despite the fact that the "kill it" request came from the author
> himself, and I believe that the current plan is to update / enhance
> the usermode utilities to deal better with the QC and give the yelling
> folks equivalent (or better) functionality. One big advantage of
> putting the driver in usermode is that it doesn't drag down your
> interactive performance anywhere near as much while using the camera.
Ugh. Please don't kill the NFS ccode[1] until after I've had a chance
to hack on it in a nice clean framework so that it can actually be made
(1) to work, and (2) to be understandable to mortals who don't have the
inclination to understand why there are all these wierd upcalls all over
the place [2].
[1] The NFS code meets both criteria: it is badly bitrotted, and not
very well maintained. I'd maintain it, but only under some very
specific conditions, namely that the house where it lives be
cleaned so I can tell the difference between real client code
errors, and general rat droppings on the mounting brackets where
it's screwed in (ie: it must not be a second class VFS consumer,
as it currently is, with system calls taking the front seat and
dictating interfaces to VFS. It is a *peer*, and should be
treated as such).
[2] As an exercise, build a kernel, then take all of the nfs objects
and link them together (ld -r -o /tmp/nfs.o nfs*.o) and then link
them against nothing, and count the number of external symbols
this supposed "FS module" imports from the kernel (besides "_main").
This will be your absolute minimal DDI/DKI for the current kernel
VFS interface as it now sits (to save you the trouble for FFS, FFS
without soft updates, and not a network consumer like NFS, depends
on ***151*** symbols. My. Isn't that *special*.).
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?199802260430.VAA23682>