Date: Thu, 10 Apr 1997 09:42:55 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: mishania@demos.su, proff@suburbia.net, hackers@freebsd.org Subject: Re: ipfilter/2.2.1 / devfs (general) Message-ID: <199704101642.JAA09371@phaeton.artisoft.com> In-Reply-To: <199704100302.NAA16451@godzilla.zeta.org.au> from "Bruce Evans" at Apr 10, 97 01:02:35 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Ifdefed options are fundamentally incompatible with LKMs. This means > that LKMs must not use nonstandard options like DEVFS, except possibly > if you keep the LKMs carefully synchronised with the kernel. And this is a problem with #ifdef'ed options, not with LKM's. > The IPFILTER and IPFILTER_LKM options are more of a problem than DEVFS > because they affect standard objects (ip_input.o and ip_output.o). A > GENERIC kernel can't possibly support an ipfilter LKM since GENERIC > isn't configured with these options. The corresponding problem for > ipfw is handled by using a negative option - COMPAT_IPFW defaults to 1. This has more to do with what should and should not be replaceable with a function point; it has more to do with the organization of the network code than with IPFILTER/IPFW. If you could replace the function entirely, it wouldn't need the #ifdef's. > The corresponding problem for file systems is very old and usually > not worried about. The union filesystem can't be an LKM because of > a couple of `#ifdef UNION's in "machine-independent" code. The ext2fs > filesystem can't be an LKM because of many `#ifdef EXT2FS's in ufs. The UNION stuff is a result of an incorrect implementation of the getdirentries() code in kern/vfs_syscalls.c, and a corresponding bogosity in the iplementation of the union specific VOP_READDIR(). It is the inability to agregate cookie values from two or more file systems that makes the union_readdir() broken. The inability to agregate, in turn, comes from the use of a user buffer for the cookie copies. VOP_READDIR() needs an overhaul, and to be split into two (or perhaps even more) seperate VOP operations. The EXT2FS code, is, from what I can see, compile time dependent, not implementation time dependent. If you look at the Lite2 CD9660 code, there are rumblings of ntegrating that into the UFS stuff as well, on the same basis. 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?199704101642.JAA09371>