From owner-freebsd-hackers Thu Oct 23 11:03:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA15092 for hackers-outgoing; Thu, 23 Oct 1997 11:03:48 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15085 for ; Thu, 23 Oct 1997 11:03:43 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id LAA15386; Thu, 23 Oct 1997 11:03:31 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd015372; Thu Oct 23 11:03:27 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA28022; Thu, 23 Oct 1997 11:03:19 -0700 (MST) From: Terry Lambert Message-Id: <199710231803.LAA28022@usr02.primenet.com> Subject: Re: Broken device LKM in 2.2 To: mike@smith.net.au (Mike Smith) Date: Thu, 23 Oct 1997 18:03:19 +0000 (GMT) Cc: archie@whistle.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199710231448.AAA00606@word.smith.net.au> from "Mike Smith" at Oct 24, 97 00:18:51 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I guess nobody makes device type LKM's in 2.2.. but sys/lkm.h is > > broken with respect to them. Here's a hack that fixes this. Perhaps > > the "name ## _module", which is different from the other module > > types, is there for some reason (?) > > IIRC it's there to avoid symbol conflicts with statically loaded > versions. Could be wrong of course; there's nothing in the CVS log. > > > Anyway, it's incompatible with the DISPATCH macro defined later in > > the file, and this fixes it... > > Has anyone looked at this? Should we buy it? You want the uniquifier. Think "disk device". A disk device LKM will want to define both a character and a block interface. To do so would result in a symbol conflict without the uniquifier. You could consider any multiheaded device in the same light; for example (bad example, I know... just let me get away with it) a Streams module that was monolithic, but defined /dev/ip, /dev/tdp, i/dev/icmp, and /dev/udp, seperately (to avoid getmsg/putmsg boundry crossing internally adding a scheduling latency per stack element boundry transition). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.