If I remember correctly, autoload bypasses the authorization calls
within the module subsystem. Autoload also works ONLY for modules that
are either built-in, passed by the bootloader, or located in the
"official" directory; autoloading from the filesystem is prohibited if
the pathname contai
> > > It would seem to be intentional. After all, kernel modules can
> > > do all sorts of nasty things if they want to.
> >
> > In that case, module autoload/autounload is not functional at all and
> > we have to specify all possible necessary modules explicitly
> > during boot time??
>
>
On Sat, Oct 16, 2010 at 11:23:29AM +0900, Izumi Tsutsui wrote:
> > It would seem to be intentional. After all, kernel modules can
> > do all sorts of nasty things if they want to.
>
> In that case, module autoload/autounload is not functional at all and
> we have to specify all possible nece
> > > XXX: module files can be loaded only on single user?
> >
> > It looks kernel modules can't be loaded on multi user,
> > i.e. if kernel securelevel is 1, unless options INSECURE is specified.
> >
> > i386 has options INSECURE by default so it just works,
> > but is it intended feature?
>
>
On Sat, Oct 16, 2010 at 11:11:07AM +0900, Izumi Tsutsui wrote:
> > Log Message:
> > Make common kernel module binaries work on both sun3 and sun3x.
> > Tested on 3/160 (on TME) and (real) 3/80.
> >
> > XXX: module files can be loaded only on single user?
>
> It looks kernel modules can't be loade
> Log Message:
> Make common kernel module binaries work on both sun3 and sun3x.
> Tested on 3/160 (on TME) and (real) 3/80.
>
> XXX: module files can be loaded only on single user?
It looks kernel modules can't be loaded on multi user,
i.e. if kernel securelevel is 1, unless options INSECURE is
On Fri, Oct 15, 2010 at 08:26:34AM +0300, Jukka Ruohonen wrote:
> On Thu, Oct 14, 2010 at 06:50:30PM -0500, David Young wrote:
> > Rather than attaching new nodes at acpi0, the system should let ACPI
> > BIOS inform the autoconfiguration process, which should attach one or
> > more instances of a n
On Fri, Oct 15, 2010 at 02:01:02PM -0400, Greg A. Woods wrote:
>
> Are there known kernel network interface incompatibilities between
> netbsd-4 and netbsd-5?
A buffer overrun in the interface ioctl code was fixed, and some formerly
working but technically incorrect programs that used to work stop
Are there known kernel network interface incompatibilities between
netbsd-4 and netbsd-5?
I mention this because in considering upgrading one of my servers from
netbsd-4 to netbsd-5 I noticed that a static-linked arpwatch binary
built on netbsd-4 was complaining about bogons on my network even tho
On 10/15/2010 01:50, David Young wrote:
Rather than attaching new nodes at acpi0, the system should let ACPI
BIOS inform the autoconfiguration process, which should attach one or
more instances of a new, MI device, display(4).
How would display(4) relate to wsdisplay(4) in this approach?
Grég
>> The task is not trivial. On modern x86, practically *everything*
>> that attachs has an ACPI counterpart. In a way we are thinking this
>> backwards: the attachment should perhaps be done via ACPI that has
>> information about the "natural" device tree
ACPI may be the source of the informatio
On Fri, Oct 15, 2010 at 10:10:18AM +0200, Martin Husemann wrote:
> On Fri, Oct 15, 2010 at 08:26:34AM +0300, Jukka Ruohonen wrote:
> > This was discussed during the development process.
>
> Where?
Already when this was first presented in 2008:
http://mail-index.netbsd.org/tech-kern/2008/
On Fri, Oct 15, 2010 at 08:26:34AM +0300, Jukka Ruohonen wrote:
> This was discussed during the development process.
Where?
Martin
On Fri, Oct 15, 2010 at 08:26:34AM +0300, Jukka Ruohonen wrote:
> The task is not trivial. On modern x86, practically *everything* that
> attachs has an ACPI counterpart. In a way we are thinking this backwards:
> the attachment should perhaps be done via ACPI that has information about
> the "natu
14 matches
Mail list logo
