The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Policy on kernel modules?

On Sat, 12 Oct 1996, Bruce Perens wrote:

> Please check out whether CONFIG_MODVERSIONS actually _helps_ and get
> back to us. In general, it made it impossible to load modules in the past!

I've been using modularized kernels with CONFIG_MODVERSIONS enabled since
1.3.8x and my modules load just fine.

I also can insmod modules from 2.0.21 into my 2.0.22 kernel without any
problems. (floppy.o, xiafs.o, binfmt_aout.o).

This is not quite what's I'd call an extensive test, but it does look like
CONFIG_MODVERSIONS works just fine. 

> How about parallel modules directories - one for modules that come from the
> kernel package and have kernel version numbers
> (and are symlinked to /usr/lib/modules/current), and one for modules from
> other sources that do not have a kernel version number. This would
> facilitate keeping multiple kernel versions on your system without
> overwriting older modules - an important goal.

Indeed! Let's please keep the two separate. The arrangement you describe
looks just fine.

   Christian


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com