--8nsIa27JVQLqB7/C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 08, 2004 at 10:35:19AM +0100, Quentin Garnier wrote:
> Le Sat, 7 Feb 2004 19:33:54 -0800
> Bill Studenmund a ecrit :
> There are already issues with our current monolithic kernel: need-count is
> not available to LKMs (neither is need-flag, but if you lack the symbols,
> you know it's not there).

One other thing about need-flag is that some of these flags also impact=20
other parts of the kernel. Like how unionfs has hooks in vfs_vnops.

I think the simple way to handle this is to have some modules only usable=
=20
if the kernel was compiled to support it.

In the terminology you are using, I think the way to do it is have a=20
"virtual attribute". It would be a static attribute that gets defined (and=
=20
thus compiled in) if either the LKM or the normal version of the code is=20
included. For the LKM case, the LKM would depend on it.

So for example:

file-system	UNION

would enable both the unionfs code and "unionfs-hooks" code.

module file-system UNION

would compile-in the "unionfs-hooks" code, and make a unionfs.ko (or=20
union.ko or whatever). unionfs.ko would not load in a kernel without the=20
"unionfs-hooks" attribute.

Not mentioning file-system UNION would get neither.

Thoughts?

Take care,

Bill

--8nsIa27JVQLqB7/C
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFAJ8h6Wz+3JHUci9cRAm2uAJwNAqbnlofOU36UMZwtUcUUziz4pgCfcScK
gejjhrYSJHz9W/R7lvECfMY=
=jLF3
-----END PGP SIGNATURE-----

--8nsIa27JVQLqB7/C--